[whatwg] element "img" with HTTP POST method

On 10.12.2010 15:52, Martin Janecke wrote:
> Am 10.12.2010 um 09:23 schrieb Julian Reschke:
>
>> It's sad that the discussion even got that far.
>
> I'm very happy about the broad feedback highlighting different aspects of the topic.
>
>> If the URI length is a problem because of browsers, fix the browsers to extend the limits, instead of adding a completely new feature.
>
> That's a good idea. Can we define a minimum length in the spec that should/must be supported? As a point of reference for browser vendors and web page authors? I didn't find a reliable point of reference other than http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.2.1 ...
>
> Note: Servers ought to be cautious about depending on URI lengths
> above 255 bytes, because some older client or proxy
> implementations might not properly support these lengths.
>
> ... which isn't sufficient for the use cases.
> ...

We can't change what RFC 2616 says, but we *did* already change this in 
the drafts for the next revision:

"Various ad-hoc limitations on request-target length are found in 
practice. It is RECOMMENDED that all HTTP senders and recipients support 
request-target lengths of 8000 or more octets." 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-12.html#rfc.section.4.1.2.p.19>

> Am 10.12.2010 um 10:03 schrieb Benjamin Hawkes-Lewis:
>
>> POST is a sort of catch-all method, but what here do you think makes
>> POST a better match than GET?
>
> I must admit that I apparently misunderstood "In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval" (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.1.1). In the LaTeX example, the request provides source code which is compiled by the remote service. The requested content isn't something that the service provider prepared before. He just offers an environment and the user defines what happens within the boundaries of this environment. I considered this to be "an action other than retrieval" only. But now I understand that for the user it has the *significance* of retrieval only, though.
>
> However, I still have the impression, that my use cases are described more precisely by the description "Providing a block of data [...] to a data-handling process. [...] The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database." (POST) than what is described in the section about GET. But I might be wrong here (and also impaired by a lack of better understanding of the English language).
>
>> See also:
>>
>> http://www.w3.org/2001/tag/doc/whenToUseGet.html
>
> Thank you for the link. In particular, I found the following passage in http://www.w3.org/2001/tag/doc/whenToUseGet.html#uris interesting:
>
> "By convention, when GET method is used, all information required to
> identify the resource is encoded in the URI. There is no convention
> in HTTP/1.1 for a safe interaction (e.g., retrieval) where the client
> supplies data to the server in an HTTP entity body rather than in the
> query part of a URI. This means that for safe operations, URIs may be
> long. The case of large parameters to a safe operation is not
> directly addressed by HTTP as it is presently deployed. A QUERY or
> "safe POST" or "GET with BODY" method has been discussed (e.g., at
> the December 1996 IETF meeting) but no consensus has emerged."
>
> A "safe POST" or "GET with BODY" would meet what I'm looking for, it seems. But clearly this is out of scope of this mailing list.
> ...

WebDAV uses SEARCH, PROPFIND and REPORT, but all of these have some 
restrictions on the response format, so probably couldn't be easily re-used.

> ...

Best regards, Julian

Received on Friday, 10 December 2010 09:06:36 UTC