struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Pratt <thechrispr...@gmail.com>
Subject Re: Mysterious(?) carriage returns
Date Mon, 06 Apr 2015 21:32:07 GMT
I believe line breaks in HTTP are always represented as <CR><LF> pairs,
regardless of the Client or Server OS's
  (*Chris*)

On Mon, Apr 6, 2015 at 2:07 PM Heikki Hyyrö <heikki.hyyro@uta.fi> wrote:

> Hi,
>
> I have been stumped by the following problem: newlines within text
> received from an html form show up in the form ”\r\n” in our Struts 2
> -based application. I am wondering how this is possible because I have
> verified the following:
>
> 1) The system is running on OS X or Linux, so the OS default newline is
> ”\n”.
>
> 2) The Java virtual machine reports ”\n” as its newline character
> (System.getProperty(”line.separator”)) when running the Struts 2
> -application in a debugger.
>
> 3) When inspecting the form text in a browser debugger, the text shows
> newlines in the form ”\n” just before the form is submitted. I
> double-checked this by inspecting the actual character code values.
>
> 4) When I set a breakpoint to the bean-setter of the corresponding action
> in the Struts 2 application and let the form submission from the browser be
> executed, the setter receives the form text as a String-parameter where the
> newlines have become ”\r\n”.
>
> What can be the reason for this? The form submission mechanism (something
> on the browser-side or in Tomcat) or the way Struts 2 handles form
> parameters before feeding them to the action? I want to get rid of these
> extra carriage returns but would very much like to find some other way than
> writing special code (such as a custom parameter interceptor) for reverting
> the text back to its original form...
>
> -Heikki
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message