On Thu, 2008-06-26 at 10:19 -0700, Dan Fandrich wrote:
> On Thu, Jun 26, 2008 at 02:09:00PM +0100, Phil Blundell wrote:
> > At the moment curl seems to react badly to an unrecognised 1xx http
> > result code. Here's a patch to make any 1xx code behave the same as
> > "100 continue", which seems to be the expected behaviour per the http
> > RFC.
>
> Does this occur in the wild? With which server and which conditions?
> This patch sound a bit dangerous. For example, the 101 response requires
> that the client switch to a different protocol, which if not done would
> result in a hung transfer or otherwise unsavoury results. The RFC reads
> a bit ambiguous to me. It talks about unexpected 1xx codes, but it doesn't
> differentiate between an unexpected 1xx code that has been defined in
> the RFC (or which there are two) or a 1xx code that has not been defined.

I've never seen it in the wild; I noticed this while testing our
application against a proprietary testsuite.

I guess I didn't make it very clear in my original mail that the current
behaviour of curl is to leave the connection hung if it encounters any
code between 101 and 199 inclusive. For all codes between 102 and 199,
there odesn't seem to be any ambiguity: either possible reading of the
RFC would indicate that you should treat them like 100.

As for 101, no matter which interpretation you place on the RFC it is
hard to see that the behaviour with this patch would be worse than that
without. Without the patch you will just get a hung transfer. With the
patch you will probably still get a hung transfer though perhaps for
different reasons. Practically speaking, though, you should never see a
101 response if you didn't send an Upgrade header, so it seems pretty
unlikely that this will be a problem in practice.

p.
Received on 2008-06-27