Re: http progress notification

tis 2010-05-25 klockan 22:38 +1200 skrev Adrien de Croy:

> we would only use this if we received a Progress token in the Connection 
> header.  Do you mean some HTTP/1.0 proxies may pass the Connection 
> header on verbatim so pass it on without understanding it?

HTTP/1.0 did not specify Connection, but that was 1997. Connection have
been around for 15 years now, and most proxies that announced themselves
as HTTP/1.0 in 2001 did implement Connection.

> I think even HTTP/1.0 required intermediaries and clients to support 
> multiple 1xx responses, so this would probably even just work.

1xx does not exists in HTTP/1.0. Reserved for future use. 


> Since the interim stage only occurs prior to the actual response (e.g. 
> 200 ok), it's not possible to be buffering an entity at the time you are 
> receiving 1xx messages from upstream.

What I was thinking about was more in line of how each step along the
path announces that it will use Progress. It's not very intuitive to the
end-user if progress indication goes up to 100% and then suddenly drops
down to 0% again when the next starts processing the response without a
prior indication that there is more steps to be taken.

> So we've discussed here possibly sending the Content-Type (and possibly 
> other headers) through to the client as well, so it can know whether 
> it's downloading something or not, and behave accordingly.   I can't yet 
> think of any requirement for other headers

Content-Disposition perhaps?

> but we could perhaps define a way to transport the headers back without
> making them actual headers of 
> the 1xx response, e.g. prefix header names with X-Orig- or encapsulate 
> them somehow into the Progress response header.  If it were just 
> Content-Type, we'd just put that through as type="..."

Should be fine to send pretty much any header in 1xx responses, but
better avoid transport headers such as an Content-Length or
Transfer-Encoding

> Have to also be careful about escaping and charsets for quoted text.

Agreed, but best if free text is avoided if possible. A token registry
for states may make sense, and application names should use the same
product bnf as used for Server.

If there is need for a free text response message then I think it's
better to add another Progress-Message header for that, defined as TEXT.
Trying to get implementations to properly quote free text tends to
always fail in a significant number of implementations.

Regards
Henrik

Received on Tuesday, 25 May 2010 14:49:28 UTC