#24 Provide access to the Http request/response headers in the webserver callbacks

[Dirk]

For dlna support it is necessary to check the http headers when receiving requests and also writing headers in the response, this is currently not possible with the webserver API and forces me to use a different web server.

[Philippe]

I'm curious what kind of changes you want to do to the header ? I recently developped a small app using libupnp to handle upnp and dlna audio players and did not have to do that. I had another problem with chunked-encoding, but this is another story

[Dirk]

If a client sets the getcontentFeatures.dlna.org=1 header, it expects a contentFeatures.dlna.org entry containing file details in the response headers

[Philippe]

As said below I've finaly done such a patch and used it exactly for that purpose

[Philippe]

Seems that the maintainers are busy. Do you feel like "we" could modify libupnp for that ? I don't have the case yet of a DLNA device complaining about that, but I might in the future. I've already modified this part of libupnp for other purposes, so I have a bit on an idea how it works

[edit]: Finally, I've added a field to the struct File_Info that is passed on the web get_info callback. It is an array of extra headers (char *name, char *value, char *resp). If the application wants to react to one of these extra headers, it should fill the corresponding "resp" with a DOMString containing HTTP response header full item. It is primitive but does the trick with not too many modifications to libupnp

[Marcelo Roberto Jimenez]

Hi Philippe,

Please, excuse me the delay, in fact I have answered this thread by e-mail, but the message has not made into the forum.

I basically said that I would review and if ok, commit any patch you submitt. Please send your patches to the appropriate tracker and I will review them.

Regards,
Marelo.

[Philippe]

Hi Marcelo - No worries, I'm not sure my patches are very well written and unfortunately, I have 3-in-ones now.
1. The defines to compile with BorlandC++/Embarcadero
2. For webserver, some complicated possibilities to handle GET with range request of 0-*with either chunked-encoding (which seems to not be fully defined in standards) or no transfer encoding (sorry I have to go through again the exact logic as it was a while ago, but I'll provide you with the details if you are interested). These modifications were necessary for me to response to many UPnP players
3- The extra headers addition

For 1. and 2. I've tried to fully respect the coding logic of libupnp where I'm afraid 3. is a bit more hacky (and I'm not a terrible programmer anyway). So let me know if this is of an interest for you and I'll provide better details

Cheers

Philippe

[Marcelo Roberto Jimenez]

Hi Philippe,

Your patches look fine, but I need them on separate files so that we can do the proper changelog documentation.

Also, please use the "git format-patch" command to generate the patches. If possible, do the "Changelog" file entry on the corresponding patches.

Regards,
Marcelo.

[Thev00d00]

Any update on this? These patches mean you could stop shipping a seperate hacked version in MediaTomb

[Marcelo Roberto Jimenez]

Hi, I've been looking at past stuff and found this thread. I don't know if there is anyone still interested in this, but I was not able to apply and test the patch:

$ patch < ../1.6.19.patch
patch: **** Only garbage was found in the patch input.

$ git apply --unidiff-zero ../1.6.19.patch
error: unrecognized input

I had asked Philippe for a unified patch, but he did not answer. Should I close this ticket?

Regards,
Marcelo.

[Philippe]

Sorry I totally forgot that. I've made a few patches against 1.6.19, to handle chunked encoding with different options for content-size and this patch for getting extra headers. Do you want a separate path for this header option? I can build one

[edit]: I've added a patch that is, to my best knowledge, a delta with 1.6.22 to get the extra header capability, the way I've implemented it. My version is 1.6.19 so I've done my best to not mix this patch with the other modifications I've made but that's a bit difficult as 1.6.19 and 1.6.22 seems to differ substancially. I don't have a test solution to try with this modified 1.6.22. If you have non-regression tests and they pass, I can see how to build a specific test for this.

I've creat a git format-patch but I'm not used to that, so I hope it's correct. Sorry for the non-fully square proposal here

[Thev00d00]

I dont think this can go into 1.6 anyway as it breaks API.

Pretty sure this is already merged into into 1.8.x

https://github.com/mrjimenez/pupnp/blob/bb994b975abf52ce9573dbca7cfd0d4e10b8c3e1/upnp/inc/FileInfo.h#L29

[Philippe]

I'm not sure it breaks the API. There is a field added in the File_Info struct which is only used at 2 places and not allocated by the user's app. So existing applications, recompiled will not see a change. Without recompiling but using a new libupnp shared lib, the structure will still work as the new field is the last, it will just not be seen by app, no?

Other that that, I did not realize that pupnp was on github, so I did a proper pull request.