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
