Re: 1xx response semantics

> One (of many) of the issues with 1xx responses is that people don't know
> how to surface two responses to one request in APIs and tools. 

For the most part, there is no reason to surface them.  The only tools
that would are the command-line tools, which typically have a --verbose mode.

> I think we could make things a bit easier for folks if we stated that
> the headers in a 1xx response are semantically not significant; i.e.,
> it's OK for APIs, etc. to drop them on the floor, because the only
> information is in the status code.

They are significant.  I don't understand why anyone would think they
are not significant -- the fields are the only way to carry information
in the interim response other than the status code.

> This would mean that people shouldn't put headers on a 1xx response and
> expect applications to see them -- which I think is already the case
> today.

No, it is not the case today.  There just isn't a large scale need for
the 1xx response handling to be implemented *today* in mainstream apps.
They can be ignored by any client that isn't deliberately choosing to
use them for upgrade or continue.   I have not seen much use for the
1xx progress indicator, partly because of the chicken-and-egg problem
with browsers.  Those applications do not ignore the header fields.
And we have no idea what 1xx codes will be introduced in the future.

....Roy

Received on Tuesday, 5 July 2011 19:39:43 UTC