Geek Answers Handbook

Firefox and Chrome replace LF CR + LF during POST

Why are Firefox and Chrome replacing the CR + LF LF character during POST?

As a test, I wrote the following:

<html> <head> <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.js"></script> <script type="text/javascript"> function lftest() { var linefeed = "before"; linefeed += String.fromCharCode(10); //linefeed linefeed += "after"; $("#field").val(linefeed); $("#formthing").submit(); } </script> </head> <body> <form id="formthing" method="post" action="http://someurl.com/resource"> <input type="hidden" id="field" value="" name="line" /> <a href="#" onclick="lftest()">send</a> </form> </body> </html>

The Developer Tools tab shows POST data:

 before%0D%0Aafter
+4
source share
2 answers

It turns out that this is due to the encoding type x-www-form-urlencoded. According to specification :

Non-alphanumeric characters are replaced with "% HH", a percent sign and two hexadecimal digits representing the ASCII character code. Line breaks are represented as pairs of “CR LF” (ie, “% 0D% 0A”).

+3
source

edit - make sure to read the insightful comment by @pepsi - all this is probably fake :-)

This is because the HTTP protocol provides that CR-LF is a line terminator for everything except the "object body" whose parameters are not part.

So a more interesting question is why Firefox (and Chrome? Not sure) extract return characters from the values ​​of <textarea> elements when they respond to requests for the "value" property of DOM elements, but they return CR at publication time. This means that the code that wants to do as the behavior of the Stackoverflow column counter must take into account the fact that the number of characters to be published does not necessarily match the number of characters in the value of the value property.

Finally, it is also interesting to note that jQuery normalizes browser behavior and ensures that the ".val ()" response for <textarea> elements always does not have CR characters, which makes it uniformly incorrect for all browsers :-)

edit - in fact, when studying RFC, it may happen that in the POST request the parameter section should be considered as the "body of the subject." If so, browsers are converted to CR-LF, perhaps just to be conservative. The servers are supposed to be really flexible with line termination agreements, but maybe they weren’t 10 years ago, and the browsers just did a simple thing and sent the normalized CR-LF pair to a safe state.

Also note that IE always did this too, sorting, but the difference is that the <textarea> value in IE is always reported with intact CR characters.

0
source

More articles:


All Articles