On tis, 2008-07-15 at 12:19 +0800, Michael Alger wrote: > I do somewhat wonder why the clients are sending HTTP/1.1 requests > to a HTTP/1.0 server in the first place, but I'm not exactly sure > how "negotiation" occurs since the client doesn't know the version > of the server until after it has sent its request. HTTP is "major version compatible" with very few exceptions. - Chunked encoding MUST NOT be used if the next hop is known or suspected to be HTTP/1.0 (goes both ways, server always knows, clients may need to guess if the server or proxy path is not yet known). - 1xx server responses (i.e. 100 Continue or 101 Switching Protocols) MUST NOT be used if the request was HTTP/1.0. Apart from this all of HTTP/1.1 fits in HTTP/1.0 without complications. Some things may be ignored by HTTP/1.0 recipients (server/clients/proxies) but doesn't make things fail if you follow the HTTP/1.1 specifications. Having clients dynamically switch between 1.0/1.1 depending on their guess of the server capabilities just calls for more implementation errors as you get lots of duplicated code implementing two almost identical protocols when all you need is just one or two simple conditions in the HTTP/1.1 implementation making it behave properly when speaking to another HTTP/1.0 implementation. These rules is very simple on the server, and trivial on the client with the exception if one wishes to use chunked encoding. Clients wishing to use chunked encoding in requests (not server responses) needs to be perpared to fall back on using content-length in the request if the server is known to be HTTP/1.0 or an 411 error is seen when trying to send a request using chunked encoding. It's valid for an HTTP/1.1 server or proxy to respond with 411 if seeing chunked encoding in an HTTP/1.1 request, so this part isn't unique to dealing with HTTP/1.0 implementations in the path.. Regards Henrik
