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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf