<div id="geary-body" dir="auto"><div>Hi, thanks for the review!</div><div><br></div>On Fri, Mar 19, 2021 at 16:42, Rémi Denis-Courmont <remi@remlab.net> wrote:<br><blockquote type="cite"><div class="plaintext" style="white-space: pre-wrap;">1) It seems like a dangerous idea from forward compatibility standpoint. It 
creates an implicit dependency on the set of headers that the library manages 
or not, which might easily break on updates.
</div></blockquote><div><br></div><div>Agreed, I based this idea on the design of the libupnp's http callbacks where they </div><div>only give you access to the headers that the http server don't process which is</div><div>awkward for the reasons you just mentionned.</div><div>IMO a better option for libupnp would just be to let the library users access the whole</div><div>set of http headers and that's it. I'll see if this is not too annoying to implement on the </div><div>libupnp side.</div><div><br></div><blockquote type="cite"><span style="white-space: pre-wrap;">2) The version dependencies in contrib and configure *must* reflect the API <br></span><span style="white-space: pre-wrap;">requirements.</span></blockquote><span style="white-space: pre-wrap;">Since I just upstreamed the patch last week, there's no libupnp release that supports</span><div><span style="white-space: pre-wrap;">that feature yet. Maybe we can wait for a release and i'll just bump to the new version</span></div><div><span style="white-space: pre-wrap;">discarding the patch in contribs.</span></div><div><span style="white-space: pre-wrap;"><br></span></div><div><span style="white-space: pre-wrap;">Regards</span></div></div>