W3C home > Mailing lists > Public > xml-dist-app@w3.org > November 2005

Re: Concern about status code 303 and resolution to Rec33

From: Yves Lafon <ylafon@w3.org>
Date: Wed, 16 Nov 2005 17:15:37 +0100 (MET)
To: noah_mendelsohn@us.ibm.com
cc: Mark Baker <distobj@acm.org>, mbaker@gmail.com, xml-dist-app@w3.org
Message-ID: <Pine.GSO.4.63.0511161710320.628@gnenaghyn.vaevn.se>

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"
    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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:28 UTC