- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 4 Jul 2013 18:22:47 +1000
- To: cowwoc <cowwoc@bbs.darktech.org>
- Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 04/07/2013, at 4:14 PM, cowwoc <cowwoc@bbs.darktech.org> wrote: > On 03/07/2013 6:19 PM, Martin Thomson wrote: >> On 3 July 2013 15:08, cowwoc <cowwoc@bbs.darktech.org> wrote: >>> If a tree falls in a forest but no one is around to see it, does it make >>> a sound? :) >> Exactly my point. Except that I think we are drawing dramatically >> different conclusions from a pragmatic perspective. >> >> I'm not sure that any of your questions are especially hard to answer, >> though I don't see how pipelining plays into this at all. > > I was going to respond with a concrete example but couldn't come up with one. On the flip side, what do you think we would lose by mandating that a server had to carry out the operation before returning HTTP 303? I mean, can you come up with a concrete optimization that would benefit from leaving this unspecified? Hi Gili, <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p2-semantics.html#status.3xx> starts: > The 3xx (Redirection) class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. So, we already say that the request isn't fulfilled when you see a 3xx. The server, by issuing a 303, is making an assertion that there's something useful at the other end; if there isn't, it's not telling the truth, and the client will have to deal with that. Making an explicit binding between receiving the entire request and the state of a completely separate resource seems like unnecessary coupling to me; how would doing so help interop? Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 4 July 2013 08:23:15 UTC