- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Wed, 22 Jul 2009 11:08:03 +0200
- To: Hugh Winkler <hughw@wellstorm.com>
- Cc: ietf-http-wg@w3.org
tis 2009-07-21 klockan 19:11 -0500 skrev Hugh Winkler:
> Thanks Mark. Let me rephrase my request. HTTP WG, please fix
> asynchronous POST. It is broken in the way I described. I once saw 202
> in an ebXML (or was it Rosettanet) environment; I've never seen
> another one used in anger. We encounter asynchronous HTTP POST all the
> time in web browsers. Not one of them uses 202.
202 is entirely fine to be used, and technically makes a lot sense in
asynchronous POST processing. The 202 response is entirely fine to
contain whatever human readable HTML application (i.e. processing status
monitor display etc) which then makes other accesses to the same or
other URIs for getting status updates if you like. If there is browsers
not displaying the 202 response then fix that issue.
What is missing from the 202 is some way for the server to indicate to
non-human agents where the resource will be created once the operation
finishes (if successful) or any estimate of when that will get done.
One thing we can do at the HTTP protocol level and which has already
been proposed is to add processing notification via a 1xx message, which
would tell the client that processing is currently under way and keep
the response channel alive until processing have finished. This allows
for long-running synchronous processing which often is the desired
action in cases one needs a status indication/monitor. May even include
%, time estimates etc if you like, but can not include any presentation
specification. Actual presentation of such processing notifications is
then left to the browser profile specifications/implementations, all
specs can do in this case is to RECOMMEND that the information is
displayed to the user somehow in interactive applications.
Another thing that can be done is to extend 202 to optionally include
the Location where the resource eventually will be available after
processing have competed combined with Retry-After telling when the
processing is expected to be finished, and even ETag if you like, which
would help non-humans to make sense of the 202 somewhat.
Another option in HTTP terms is to return 201 (maybe with Retry-After)
but respond with 503 + Retry-After in requests to the URI until
processing have actually finished. The 503 responses MAY include human
oriented status updates including a status monitor application.
The part about GET to the created URI returning 503 + Retry-After is
actually equally valid for both 201/202 cases above.
> The WG ought to do something so that all kinds of user agents - web
> browsers as well as B2B XML systems -- can do asynchronous POST
> using a uniform interface.
Care to explain again what the issue with 202 is in this context?
> A server ought not care what kind of client
> has POSTed to it, web browser or B2B agent software; in either case
> the protocol interaction ought to be the same.
Agreed, but the desire of web masters to add custom interfaces to
everything instead of demanding web browser vendors to display HTTP
actions in a sensible way often works against this, making authors of
human intended applications completely ignore protocol semantics like
the difference in 200/201/202/303 in a case like this, just returning
whatever they happened to like for the day (i.e. 303 if they want to
display a human oriented processing indicator, causing issues for
non-humans trying to use the same)
> The origin server MUST create the resource before returning the 201
> status code.
> If the action cannot be carried out immediately, the server SHOULD
> respond with 202 (Accepted) response instead.
>
> So the spec says you SHOULD return 202 if you must create a resource
> asynchronously. Can't we permit redirects too? SHOULD is pretty strong
> language.
That SHOULD is intended to be read in context of the previous sentence.
But I agree it's confusingly written and should go away, possibly
replaced by a note along the lines
"If the action cannot be carried out immediately, the server
should respond with another suitable response such as 202
(Accepted) instead".
> The spec has never said anything about what to do in case you receive
> a 202 in response to a GET.
Pretty much the same as when you get a 200. The enclosed entity is
intended to be displayed to the (human) user, just as a 200 response is,
with the difference in status code mainly intended for non-humans.
> Please just tell us what it means to get
> 202 in response to GET. Is it illegal?
It's not illegal, just very odd as GET isn't supposed to have any
significant effects beyond information retrieval so it doesn't make much
sense (in HTTP terms) that a GET operation can be executed outside of
the GET operation itself.. But as HTTP does not forbid GET from having
significant sideeffects it's theoretically possible that returning 202
makes sense to some application...
Regards
Henrik
Received on Wednesday, 22 July 2009 09:08:41 UTC