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."
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.