- From: Sergey Beryozkin <sberyozkin@zandar.com>
- Date: Thu, 25 Sep 2003 22:55:13 +0100
- To: "Mark Baker" <distobj@acm.org>
- Cc: "Sergey Beryozkin" <sberyozkin@zandar.com>, <www-archive@w3.org>
Hi Mark, > > While REST requires uniform connector semantics, it doesn't prevent > > those semantics from being specialized, so long as --- key point > > here --- any expectation of specialized semantics is indicated as part > > of the message in a self-descriptive manner. Consider that when I was > > talking about "confused intermediaries", that an intermediary would not > > be confused if it knew that an extension was in use that it didn't > > understand. Given that, "echo" might best be done like this; > > > > POST http://some-host/some-uri HTTP/1.1 > > Mandatory-Intent: http://example.org/standard-resource-types/echoer > > [body goes here] If I understand it correctly, a mandatory-intent header could explicitly say that semantics of a given (POST) request are specialized, for ex, it could indicate that a document in a POST request body will be echoed immediately back, or will be sent separately by a server to a provided URL, etc. The question is about intermediaries. It sees that it does not recognize a given extension so it does not process this request as usual in line with the semantics of the current method (POST, etc), but, perhaps, just forwards this request to the next destination. Wouldn't it present some other problems (security, etc) ? > > There, I would have used "SOAPAction", except that SOAPAction doesn't > > support a mandatory strength declaration; i.e. it can't say "this > > extension is critical to understanding the semantics of this message". What is required for "SOAPAction" to support it and for external parties to recognize that "SOAPAction" specifies such an extension ? > > > Can you please send me a link to a correspondig WebServices Activity > thread > > > you refer to in those comments ? > > > > http://lists.w3.org/Archives/Public/xml-dist-app/2002Jan/thread.html#416 Thanks, some questions: Am I right in assuming that a http://www.intertwingly.net/wiki/pie/DifferentlyAbledClients proposal allows for tunneling GET within POST while your proposal allows for using a pure GET but also extending it by passing additional metadata, such as SOAP headers ? It seems to me now that it's not prohibited to pass some data in a GET body, provided that those data do not indicate that a targeted resource be modified. As you indicated, SOAP headers of idempotent nature could be passed ok. Please don't be shocked :-), by why then it's wrong to pass GET parameters in an envelope Body (provided that those parameters are just query parameters) ? How much query parameters add to a visibility of a resource ? I'm not sure but it seems that they're of use to a resource handler, but not of much help to intermediaries. I just don't understand what is the right way to tunnel GET within POST. Such tunneling could be applied to uses of SOAP Http Binding, which requires POST for all requests. The first step is to indicate the fact of tunneling with SOAPAction, but what about the Body, will it have to turn itself into POST parameters ? Probably yes ... Cheers Sergey
Received on Thursday, 25 September 2003 17:58:57 UTC