[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1495419 - in /subversion/trunk/subversion/libsvn_ra_serf: options.c ra_serf.h serf.c util.c

From: <kmradke_at_rockwellcollins.com>
Date: Fri, 21 Jun 2013 11:18:35 -0500

> > 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

This is an archived mail posted to the Subversion Dev mailing list.