On Sat, Jun 22, 2013 at 9:08 AM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Ivan Zhakov <ivan_at_visualsvn.com> writes:
>
>> Problem with this approach that some servers may support HTTP/1.1
>> partially. I.e. declare them as HTTP/1.1 but do not support chunked
>> Transfer-Encoding.
>>
>> I wanted to avoid downgrade to HTTP/1.0 on later requests because it
>> could introduce requests ordering issue. For example:
>> C: HTTP/1.0 OPTIONS /
>> S: HTTP/1.1 Response
>>
>> C: HTTP/1.1 PROPFIND
>> C: HTTP/1.1 GET
>> S: HTTP/1.1 411 Length required
>> S: HTTP/1.0 200 OK
>>
>> Then client send PROPFIND request again:
>> C: HTTP/1.0 PROPFIND
>> S: HTTP/1.1 200 OK
>>
>> But requests was completed and different order than our update editor
>> expected and most likely crash :(
>
> Suppose serf were to keep track of the number of outstanding requests
> (it may already do that I haven't checked). Then if the number of
> outstanding requests is zero when the 411 is received the downgrade to
> HTTP/1.0 will be OK. Lots of client operations start with multiple
> requests in serial before switching to pipelined requests, so in all
> those cases the downgrade will work.
We need a solution for all cases, most is not enough.
Given the requirement of the first request's mandatory http/1.0 and
strict ordering of req/resp in pipeline mode, I don't see how we can
identify both http/1.1 compliance and chunked encoding support with
only one non-pipelined request.
Why not play it safe then and send one extra request on the first
connection in the context?
The first request is a HTTP/1.0 request to detect if the connection
can be upgraded to HTTP/1.1.
The second request (the PROPFIND) is sent using chunked encoding to
detect if that's supported.
If 411 is received fallback to HTTP/1.0 mode, otherwise continue with
HTTP/1.1 + chunked encoding.
This will add one round-trip of overhead for every serf session, and
it impacts all users, even those that are not behind such (outdated)
proxies.
I'd support making this dependent on a 'http1.0_server" option in the
servers runtime configuration. With this option it only impacts those
users that are working behind outdated proxies. We can include the
necessary instructions for users in the error description of the
by-default-unexpected 411 response.
This should also be a clear trigger for hosting companies to upgrade
their proxy infra.
> --
> Philip Martin | Subversion Committer
> WANdisco | Non-Stop Data
> www.wandisco.com
Lieven
Received on 2013-06-22 10:08:19 CEST