Re: Concern about status code 303 and resolution to Rec33
Yves Lafon <[email protected]>
| Newsgroups | gmane.text.xml.distributed |
|---|---|
| Message-ID | <[email protected]> |
On Wed, 16 Nov 2005, [email protected] wrote: > > Mark Baker writes: > >> My understanding is that 303 indicates "Ok, I've done the >> [POST], but if you want the results ( i.e. what would normally >> be returned on the POST response), you'll have to invoke GET on >> this other resource to get them". > > An important clarification, thanks. I think this gets to the crux of the > matter. If 303 reliably means: "I've seen and taken responsibility for > acting on your POST, I've therefore applied the full SOAP processing > model, but for whatever reason your response envelope or fault envelope > can be retrieved from this other URI", then I agree the resolution > proposed is OK. If it means: "I'm not sure I want to do your POST, but > try a GET here and you'll find out something interesting", then I agree > the resolution is basically OK. > > Presuming it is indeed the former, maybe we should add to the part of the > binding that handles responders clause along the following lines: Also note, from rfc2616, about POST being not cacheable "by default" <<< However, the 303 (See Other) response can be used to direct the user agent to retrieve a cacheable resource. >>> > > "Status code 303 MUST NOT be sent unless the request SOAP envelope has > been processed according to the SOAP processing model and the SOAP > response is to be made available by retrieval from the URI provided with > the 303." That sounds like a good clarification. -- Yves Lafon - W3C "Baroula que barouleras, au tiéu toujou t'entourneras."