- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Fri, 13 Aug 1999 23:42:02 PDT
- To: Keith Moore <moore@cs.utk.edu>, "Herriot, Robert" <Robert.Herriot@pahv.xerox.com>
- Cc: ipp <ipp@pwg.org>, HTTP Working Group <http-wg@hplb.hpl.hp.com>
> (connection opened) > >>> GET /printer/status/job#2343 HTTP/1.1 > >>> > <<< Content-type: application/ipp-status-messages > <<< > (pause) > <<< status: page 1 printed > (pause) > <<< status: page 2 printed > (pause) > <<< status: page 3 printed > (pause) > <<< status: out of paper > (pause) > <<< status: resumed > (pause) > <<< status: page 4 printed > <<< status: job complete > (connection closed) I don't like this example (of using GET for printer status) without any cache-control headers, and with the presumption that the entity body is streamed with indefinite pauses. I know people do this, but I'd be reluctant to recommend it, because it interacts badly with caches and will the recommended semantics of HTTP as a request/response protocol. If one of the (pause)s is, say, a minute, some intermediary might just break off the connection as stalled. And then there's no particular guarantees of completeness. A proxy might legitimately want to buffer the entire response, sending back '100 continue' messages, and then batch the entire message body. Also, the URI has a problem: /printer/status/job#2343 Since '#' is a reserved character for fragment delimiter, and HTTP URIs don't de-encode the data, this is not a good example.
Received on Friday, 13 August 1999 23:45:54 UTC