On Aug 6, 2008, at 11:59 AM, Julian Reschke 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).
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.
- 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.
- 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.
Lisa
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf