Subject: [alto] Should get-mode services accept post requests?

From: Wendy Roome <[email-masked]>
Date: Wed, 16 Jul 2014 11:10:21 -0400

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?

	- Wendy

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 17 Jul 2014 09:26:28 +0200

On Wed, Jul 16, 2014 at 11:10:21AM -0400,
 Wendy Roome <[email-masked]> wrote 
 a message of 29 lines which said:

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

Note that a regular HTTP server, serving static data (such as a
network map), accepts POST and generates the same reply as a GET.

% curl -v -X POST http://www.ietf.org/meeting/90/index.html 
...
> POST /meeting/90/index.html HTTP/1.1
> User-Agent: curl/7.37.0
> Host: www.ietf.org
> Accept: */*
> 
< HTTP/1.1 200 OK
< Server: cloudflare-nginx
< Date: Thu, 17 Jul 2014 07:25:27 GMT
< Content-Type: text/html
...

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 17 Jul 2014 08:39:51 +0100

Wendy,

> 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

---

From: Wendy Roome <[email-masked]>
Date: Thu, 17 Jul 2014 15:51:20 -0400

Yes, most web servers accept POST as well as GET. But most web pages don't
have an RFC defining their content. :-)

Also, regular web pages generally use POST for form submission. Form-field
encoding is well-defined for both POST & GET requests, so except for the
low-level field decoding, web servers can treat GET & POST identically.
The difference is only important in the browser (for caching) or in
proxies along the way.

	- Wendy Roome

---

From: Wendy Roome <[email-masked]>
Date: Thu, 17 Jul 2014 16:00:24 -0400

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.

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-masked]> wrote:

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

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 18 Jul 2014 06:38:20 -0400

Hi Wendy, Ben,

Always interesting, insightful observation. Please see below.

> 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

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: Wendy Roome <[email-masked]>
Date: Fri, 18 Jul 2014 10:18:15 -0400

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-masked]>
Date:  Fri, July 18, 2014 at 06:38
To:  Wendy Roome <[email-masked]>
Cc:  Ben Niven-Jenkins <[email-masked]>, IETF ALTO <[email-masked]>
Subject:  Re: [alto] Should get-mode services accept post requests?

Hi Wendy, Ben,

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

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 18 Jul 2014 16:56:36 -0400

Wendy,

> On 17 Jul 2014, at 16:00, Wendy Roome <[email-masked]> wrote:
> 
> Ben,
> 

Not really as the semantics can be defined in terms of the Content-Type of the POST. 

> Filtered Map services. Eg, consider this IRD fragment:

Good point - for some cases the semantics of POST are defined. 

For cases where the semantics of POST to a URI are not communicated as part of the IRD or some other out of band means I could live with saying the ALTO server SHOULD return an error (but I don't think we should define the precise status code). 

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 18 Jul 2014 17:27:13 -0400

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-masked]> 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
> 
>> On Thu, Jul 17, 2014 at 4:00 PM, Wendy Roome <[email-masked]> wrote:
>> Ben,
>> 
> 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:
>    ...
> 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
>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 18 Jul 2014 21:20:17 -0400

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-masked]>
wrote:

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