GNOME Bugzilla – Bug 702555
7.2.5.6,7.4.23.3: Always use HTTP 1.1, even if the peer requests HTTP 1.0
Last modified: 2014-06-14 15:27:19 UTC
I think it's a libsoup default to mirror the version of the peer.
Created attachment 247242 [details] [review] Force HTTP version 1.1 on SOAP requests This is for 7.2.5.6 - not sure wether we really should do this, though. Although soup uses 1.1 by default anyway.
Created attachment 247243 [details] [review] server: Force HTTP version to 1.1
This patch seems to break 7.2.5.5 and 7.2.6.1,2
Ah, because HTTP 1.1 doesn't have connection: close as default :-/
Created attachment 247251 [details] [review] Force HTTP version 1.1 on SOAP requests Second version, close connection as HTTP 1.0 would.
Created attachment 247252 [details] [review] server: Force HTTP version to 1.1
Comment on attachment 247251 [details] [review] Force HTTP version 1.1 on SOAP requests Attachment 247251 [details] pushed as 27e2dbe - Force HTTP version 1.1 on SOAP requests
Attachment 247252 [details] pushed as ed6b267 - server: Force HTTP version to 1.1
Review of attachment 247252 [details] [review]: ::: src/librygel-server/rygel-http-request.vala @@ +59,3 @@ + msg.response_headers.append ("Connection", "close"); + } + I think the way this is done should be revisited. While DLNA requires a server to respond as being 1.1 to a 1.0 request, it's still required to formulate the response with 1.0 headers. But this block prevents downstream logic (e.g. HTTPGet) from being able to add version-sensitive logic (the fact that it's a 1.0 request is lost). I'm thinking the set_http_version() could be called just before the message response is sent. I'll try to come up with a specific recommendation...
Is this causing any problems? Should we reopen the bug?
Sorry - missed your (quick) reply. And been at DLNA Plugfest. The issue is that if you need to formulate the response according to the HTTP version of the client request (e.g. DLNA 7.5.4.3.2.34/.35 mandates different caching response headers based on the HTTP version), I don't see a way to tell the difference in the Soup message once "set_http_version (Soup.HTTPVersion.@1_1)" is called (Soup doesn't seem to have separate request & response "http_version" properties). And this call is made when the HTTPRequest object is constructed (and before and of the HTTPGet/HTTPGetHandler logic runs). Attaching an possible alternative.
Created attachment 269501 [details] [review] Alternate way to set the HTTP response version to 1.1 for 1.0 requests This patch causes "set_http_version (Soup.HTTPVersion.@1_1)" to be called near the end of HTTPGet.handle_item_request instead of in the HTTPRequest constructor.
Ah ok. so this was set too early.
Yeah - too early. Of course the code with the HTTP 1.0 isn't in master. But I'll update the patch on bug 720223 with the dependant code (that implements 7.5.4.3.2.34/.35 and passes the new CTT tests) shortly.
(^ with the HTTP 1.0 *check*... ^)