Thomas Roessler wrote:
Lisa:
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).
Julian:
Oh, I thought it uses POST, but maybe I missed something.
Section 9 of draft-08 seems to specify behavior for GET and
body-less POST as "MUST attempt to provide either a PIDF/LO document
or a Location URI".
The use of HTTP/HTTPS also includes a default behaviour, which is
triggered by a GET request, or a POST with no request body. If
either of these queries are received, the LIS MUST attempt to provide
either a PIDF-LO document or a Location URI, as if the request was a
location request.
Yes, that's why I was talking about. I don't see a requirement to use
GET with a body (which would be an interesting experiment).
Now, I don't know what "attempt" means in that context, but leaving
that point aside, it sounds to me like that's leaning into a
direction that could make the spec work perfectly well with a
browser as a client, assuming there's a handler for
application/held+xml.
The example in 11.1 uses a GET message without a body.
Yes.
As far as I understand, HELD is used to query for location information.
Right now, the details of the query are encoded in a POST body as
defined by the XML Schema in
<http://tools.ietf.org/html/draft-ietf-geopriv-http-location-delivery-08#section-7>.
A GET works the same way as an empty POST request (as shown in 11.1).
This really smells like over-engineering.
Why aren't these things simple query parameters in a GET request?
BR, Julian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf