> > On Jun 21, 2013 10:36 AM, "Ivan Zhakov" <ivan_at_visualsvn.com> wrote:
> > >....
> > > >> 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.
> > > >
> > > > Then fix that problem. Add a flag saying "busted_http11" and make
it
> > > > send requests with Content-Length after that.
> > > >
> > > Do you mean run-time configuration option like "http-force-http10 =
yes"?
> > Oh. Hadn't thought about that. I was thinking dynamic detection.
> > I would favor dynamic over Yet Another Config Option, but you're the
> > one writing this code right now :-)
>
> Dynamic is the right approach because the spec does allow a 1.1 proxy
> to return a 411 to a chunk encoded request:
>
>
http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-22#section-3.3.3
>
> (This will obsolete 2145 and 2616 if/when approved)
>
> This is validated (albeit discouraged) by the the chair of that working
group:
>
> http://www.mnot.net/blog/2011/07/11/what_proxies_must_do
The httpbis spec further says:
Unless a transfer coding other than chunked has been applied, a
client that sends a request containing a message body SHOULD use a
valid Content-Length header field if the message body length is known
in advance, rather than the chunked transfer coding, since some
existing services respond to chunked with a 411 (Length Required)
status code even though they understand the chunked transfer coding.
This is typically because such services are implemented via a gateway
that requires a content-length in advance of being called and the
server is unable or unwilling to buffer the entire request before
processing.
I haven't looked at the serf code, but I would assume most request
message bodies would have a known size, so serf really should be
preferring to send content-length instead of chunked encoding
for request messages.
Kevin R.
Received on 2013-06-21 18:19:08 CEST