Re: Concern about status code 303 and resolution to Rec33

On Wed, 16 Nov 2005, noah_mendelsohn@us.ibm.com 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."

Received on Wednesday, 16 November 2005 16:18:13 UTC