ietf
[Top] [All Lists]

Re: Past LC comments on draft-ietf-geopriv-http-location-delivery-08

2008-08-06 12:25:10
Lisa Dusseault wrote:
Is the concern that a client that does a GET on an HTTP URI, and receive a response with that MIME type, still wouldn't know whether it's seeing a genuine HELD response, or just some static XML document served by a web server?

Before that failure, there's the problem that a GET to a HELD server requires a custom body. A GET without that body is undefined (in the last spec version I remember).

Oh, I thought it uses POST, but maybe I missed something.

That issue was on my list anyway; I just didn't want to distract from the URI issue. A HELD request should be safe, so it probably would be good if it could always be put into a GET request (for instance, using query parameters).

Another way to address this would be for a HELD server to be REQUIRED to respond to an empty-body GET with a "here's what you need to do with this URL" response, either user-readable or machine-readable (MIME type). That could be part of an alternative to a HELD-specific URI scheme.

As far as I can tell, the current spec always uses POST (not good for something that essentially is just a query), and allows GET as a fallback for the canonical case.

Yes, your proposal would work, but wouldn't it be much simpler to put the parameters into request-URI and always use GET?

- RFC2616 requires servers to understand requests with an absoluteURI as request-URI, but it also tells HTTP/1.1 clients not to use it (except when talking to proxies); so you're moving outside the HTTP/1.1 spec

That's OK, because HELD moves outside the HTTP/1.1 spec in several ways. A HELD client can be told to use the absolute URI, thus overriding the general-purpose requirement in 2616. Extensibility sometimes requires these kind of defaults and exceptions.

What I'm concerned with is that by doing so, you loose the ability to use available HTTP/1.1 client libraries.

- existing client libraries (such as XHR or Apache HttpClient) do not support this format (and why should they?), so how do you get the request on the wire if not by writing a custom http stack?

This is a more serious problem. Requiring a custom HTTP client stack would be drawback to the new-scheme approach.



- how do you implement a server on top of existing HTTP frameworks, such as in a Java servlet container? Are there extension hooks that allow this?

I do not know if that's important to HELD server developers.

Ok, are thesee extension hooks in Apache or IIS?

BR, Julian


_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>