I also agree with the text suggested by Wendy, with a small edit: In particular, for a resource that uses the GET method,
=〉 In particular, for a resource that is specified in this document to use the GET method, OK? Richard On Jul 19, 2014 5:27 AM, "Ben Niven-Jenkins" <[email protected]> wrote: > Wendy, > > Your suggested text works for me. > > Ben > > P.S. Whether some frameworks/origins unify GET and POST shouldn't drive > what we specify IMO as the semantics of GET and POST are different, e.g. > GET carries the semantic of idempotency which POST does not. > > On 18 Jul 2014, at 10:18, Wendy Roome <[email protected]> wrote: > > Let me cut to the chase: I suggest that we add the following to the ALTO > Errata sheet, probably as a new paragraph at the end of "8.3.2. Client > Requesting Information Resources": > > “An ALTO Client MUST NOT assume that the HTTP GET and POST methods are > interchangeable. In particular, for a resource that uses the GET method, an > ALTO Client MUST NOT assume that resource will accept a POST request as > equivalent to a GET request." > > I think that is much less controversial than requiring a server to return > an error. > > As for unifying GET & POST, yes, I agree most web servers try to unify > them. For static pages, I believe Apache returns the same result for GET & > POST (at least by default). As for dynamic pages, I think most libraries > unify them, although some do not. E.g., in Java Servlets, the servlet must > override a Java method for each HTTP method: doGet(), doPost(), > doOptions(), doHead(), etc. > > However, I believe libraries that unify GET & POST still provide a > function that returns the method, so scripts can always distinguish between > GET & POST if desired. That's certainly the case in Richard's perl > example. > > I also agree that RFC 2616's section on POST is techno-babble at its > deadliest. :-) But at least the subsequent paragraphs reveal the reality: > the script can do whatever it wants to. I believe the only important point > in that section is the statement that POST responses are not cacheable. The > rest is just hand-waving; it doesn't put any obligations on the client or > the server. > > - Wendy Roome > > From: "Y. Richard Yang" <[email protected]> > Date: Fri, July 18, 2014 at 06:38 > To: Wendy Roome <[email protected]> > Cc: Ben Niven-Jenkins <[email protected]>, IETF ALTO <[email protected]> > Subject: Re: [alto] Should get-mode services accept post requests? > > Hi Wendy, Ben, > > Always interesting, insightful observation. Please see below. > > On Thu, Jul 17, 2014 at 4:00 PM, Wendy Roome <[email protected]> > wrote: > >> Ben, >> >> However, if a significant number of ALTO servers accept POST as well as >> GET for full map services, that will establish a de-facto standard, and it >> will be difficult to define different semantics for POST in the future. >> > > > Good discussion. Out of curiosity, I looked up POST in wikipedia :-), and > found this statement in the first paragraph: "The POST request method is > designed to request that a web server accept the data enclosed in the > request message's body for storage." Hence, using POST as an update fits > this description well, although many servers treat GET and POST the same in > many cases. > > I still remember the days when I used perl for CGI, and it always starts > with the segment: > ... > $ENV{'REQUEST_METHOD'} =~ tr/a-z/A-Z/; > if ($ENV{'REQUEST_METHOD'} eq "POST") > { > read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'}); > } else { > $buffer = $ENV{'QUERY_STRING'}; > } > > If the preceding "unification" statement is in a library, the ALTO Server > programer may not know if $buffer is from GET or POST. > > RFC 2616 has the following statement that I never fully understood: "The > POST method is used to request that the origin server accept the entity > enclosed in the request as a new subordinate of the resource identified by > the Request-URI in the Request-Line." But there is the following statement, > although not to my taste, makes the main, practical point: "The actual > function performed by the POST method is determined by the server and is > usually dependent on the Request-URI." In other words, for one given > Request-URI, GET and POST may return the same result, while for another > URI, they may differ. I feel that your example below fits into the > category. > > In more details, consider the "bad" case of a single Request-URI uri being > announced by multiple services: (1) full map; (2) filtered map; (3) update > to an map. We know that the correct method should be GET, POST, POST > respectively. Assume that the app does not check if the request is GET or > POST, for example, due to using a "unifying" library. One "redundancy" that > the current protocol spec has is the Content-type: (1) has no Content-type; > (2) should have application/alto-networkmapfilter+json and (3) will be > something such as "application/alto-networkmapupdate+json. In other words, > we have some build-in decoding redundancy to resolve the issue you > mentioned below. Assume that we use only json as the type, then (2) and (3) > cannot be distinguished. > > Make sense? > > Richard > > Also, the current spec allows a server to use the same URI for Full and >> Filtered Map services. Eg, consider this IRD fragment: >> >> "my-default-network-map" : { >> "uri" : "http://alto.example.com/networkmap";, >> "media-type" : "application/alto-networkmap+json" >> }, >> "filtered-network-map" : { >> "uri" : "http://alto.example.com/networkmap";, >> "media-type" : "application/alto-networkmap+json", >> "accepts" : "application/alto-networkmapfilter+json", >> "uses": [ "my-default-network-map" ] >> }, >> >> That says that for http://alto.example.com/networkmap, GET returns a full >> network map, while POST (with the appropriate content type) returns a >> filtered network map. >> >> - Wendy Roome >> >> >> On 07/17/2014, 03:39, "Ben Niven-Jenkins" <[email protected]> >> wrote: >> >> >Wendy, >> > >> >On 16 Jul 2014, at 16:10, Wendy Roome <[email protected]> >> wrote: >> > >> >> Here is a fringe case that doesn't seem to be covered in the protocol >> >>spec. >> >> >> >> If a client sends a POST request to a GET-mode service, like Full Cost >> >> Map, should the ALTO server reject the request? Or should the server >> >> accept the request anyway, and just return the map? >> >> >> >> And would it depend on the content the client sent? Eg, should the >> >>server >> >> accept a POST request with no content, but reject a POST request if the >> >> client sent a body of (say) type application/alto-costmapfilter+json, >> on >> >> the grounds that the client mistakenly thought this was a Filtered Cost >> >> Map service? >> >> >> >> My inclination is to reject an POST request, even if there is no >> >>content. >> >> Normally I prefer to forgive obvious errors, but unless all servers >> have >> >> the same level of forgiveness, error-tolerant servers will be seen as >> >> "correct", while other servers will be seen as "incorrect". >> >> >> >> What does the group think? >> > >> >My view is that the behaviour is server implementation specific and that >> >clients must not rely on a particular response unless they have further >> >information to suggest otherwise. >> > >> >I don¹t like the idea of mandating returning an error as I¹d like to >> leave >> >the door open to allowing POST later on, e.g. as a possible means to >> >update >> >the map. >> > >> >Ben >> > >> >> >> _______________________________________________ >> alto mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/alto >> > > > > -- > -- > ===================================== > | Y. Richard Yang <[email protected]> | > | Professor of Computer Science | > | http://www.cs.yale.edu/~yry/ | > ===================================== > >
_______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
