Martin Janecke <[email protected]> schrieb am Thu, 9 Dec 2010 19:59:02 +0100:
> What is your opinion on enabling the HTTP POST method for the img > element? The motivation behind this is that there are services which > generate images automatically based on parameters given -- nowadays > provided as query string in a GET request -- for inclusion in web > pages. I've listed examples below. However, these query strings can > get really long and it seems to me that the HTTP POST method would be > more appropriate than the GET method for such services. Not only > because it would better match the intended use of these methods (see > http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9), I do not agree. Maybe I do not grasp something here, but I was of the impression that POST creates content while GET requests resources, also explicitly resources that are created by “data-producing process[es]”. Also, quote RFC 2616, Section 9, Subsection 5: > 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. I don't see this with image generation at all. Back to your mail: > but also > for practical reasons: URLs in GET requests are (inconsistently) > limited in length by browsers and server software, which limits these > services (inconsistently). And long URLs bloat server logs. These are implementation issues. What makes you believe that the relatively complex task of adding a new attribute would be implemented before the relatively simple task of extending the URL length? Also, filtering out GET variables from logs is a simple task. > This could be implemented with an optional attribute, e.g. > "post-data". The client would request the source using the POST > method if the attribute is present and send the attribute's value as > the request's message body. New clients. What would old clients do? What if the given URL contained GET variables? > […] > > === Example/Use Cases === > > (1) MimeTeX and MathTeX are used to display mathematical formulae in > web pages. This is often used in science forums. Info: > > […] Why not use inline MathML? It is semantically accurate and stylable. > […] > > <img > src="http://qrcode.kaywa.com/img.php?s=8&d=Ah%2C%20distinctly%20I%20remember%20it%20was%20in%20the%20bleak%20December%2C%0D%0AAnd%20each%20separate%20dying%20ember%20wrought%20its%20ghost%20upon%20the%20floor."; > alt="qrcode"> > > Possible future use: > > <img src="http://qrcode.kaywa.com/img.php"; > post-data="s=8&d=Ah%2C%20distinctly%20I%20remember%20it%20was%20in%20the%20bleak%20December%2C%0D%0AAnd%20each%20separate%20dying%20ember%20wrought%20its%20ghost%20upon%20the%20floor." > alt="qrcode"> This seems to be largely an aesthetical (but non-backwards-compatible!) change. Also, at least to me it does not seem to be “more” readable. Cheers, -- Nils Dagsson Moskopp // erlehmann <http://dieweltistgarnichtso.net>
signature.asc
Description: PGP signature
