One Request, Multiple Responses

i just ran across draft-decroy-http-progress, which proposes a new Progress HTTP header for communicating progress messages from upstream HTTP servers to downstream HTTP clients. the idea is that HTTP servers can send progress responses, so that HTTP clients do not time out and users can see some useful progress indicator. nice idea, in principle.

however, the draft seems to propose a model where there is one request being sent, and as a result, the client receives multiple responses, each of them containing some progress indication. that does not look like HTTP to me, but maybe i am missing some important part of the HTTP spec that allows this kind of 1:n message exchange pattern?

it seems to me that HTTP's rather simple request/response pattern simply is not very good at supporting a tighter coupling between clients and servers to allow this kind of intermediary messages.

HTTP's response definition states that after receiving and interpreting a request message, a server responds with an HTTP response message, and to me this sounds like a 1:1 pattern, but maybe it is not as 100% clear as one might wish. is there another place in the HTTP spec which explicitly talks about message exchange patterns?

Comments

[Adrien de Croy]

Hi

Just saw your comments on my I-D. The spec for HTTP (RFC2616) mentions interim responses, with status codes in the range 100 - 199.

It states that HTTP agents must be prepared to receive any number of interim responses prior to the final response (2xx - 5xx).

I've never actually seen more than 1 interim response (e.g. IIS responds with "100 continue" to a POST request, followed by another response message with the actual result of the POST). But this already is 1:2 for POST, which indicates User agents have already been coded to deal with interim responses.

The requirement for agents to handle any number of interim responses means this proposal doesn't contravene the spec in terms of message flow.

[dret]

thanks a lot for your comment, adrian!

http://tools.ietf.org/html/rfc2616#section-10.1 indeed states that "a client MUST be prepared to accept one or more 1xx status responses prior to a regular response". so http definitely allows 1:n message patterns, and not only 1:1.

http://tools.ietf.org/html/rfc2616#section-6 however says (like i wrote in my original post) that "after receiving and interpreting a request message, a server responds with an HTTP response message".

these two statements are not completely contradicting, but at least not as clear as one might wish. i found the quote in section 6 and (wrongfully) concluded that there would be just one response. maybe this part of the spec also would be a candidate for the ongoing effort to create a clarified version of the http spec (http://www.ietf.org/html.charters/httpbis-charter.html)?