Author: cziegeler
Date: Wed Dec 11 00:03:16 2013
New Revision: 1550003
URL: http://svn.apache.org/r1550003
Log:
CMS commit to sling by cziegeler
Modified:
sling/site/trunk/content/documentation/the-sling-engine/request-parameters.mdtext
Modified:
sling/site/trunk/content/documentation/the-sling-engine/request-parameters.mdtext
URL:
http://svn.apache.org/viewvc/sling/site/trunk/content/documentation/the-sling-engine/request-parameters.mdtext?rev=1550003&r1=1550002&r2=1550003&view=diff
==============================================================================
---
sling/site/trunk/content/documentation/the-sling-engine/request-parameters.mdtext
(original)
+++
sling/site/trunk/content/documentation/the-sling-engine/request-parameters.mdtext
Wed Dec 11 00:03:16 2013
@@ -1,7 +1,6 @@
Title: Request Parameter Handling in Sling
Excerpt: Explains how Sling provides request parameters to the `Component`.
-
## Servlet API
The Servlet API specification provides the following methods to access the
parameters of a request
@@ -48,15 +47,15 @@ Be warned: Only rely on request paramete
Traditionally, the encoding of parameters, especially in text area input
forms, has been a big issue. To solve this issue Sling introduces the following
convention:
- * All forms should contain a hidden field of the name `\*charset\*`
containing the actual encoding used to send the form from the server to the
client
+ * All forms should contain a hidden field of the name
<code>_charset_</code> containing the actual encoding used to send the form
from the server to the client
* All forms should be sent with *UTF-8* character encoding
The first rule is essential as it helps decoding the form input correctly. The
second rule is not actually a very hard requirement but to enable support for
all (or most) character sets used, using *UTF-8* is one of the best choices
anyway.
-When Sling is now receiving a request and is asked for the parameters, the
parameters are parsed in two phases: The first phase just parses the raw input
data using an identity transformation of bytes to characters. This identity
transformation happens to generate strings as the original data was generated
with `ISO-8859-1` encoding. The second phase locates the `\*charset\*`
parameter and fixes the character encodings of the parameters as follows:
+When Sling is now receiving a request and is asked for the parameters, the
parameters are parsed in two phases: The first phase just parses the raw input
data using an identity transformation of bytes to characters. This identity
transformation happens to generate strings as the original data was generated
with `ISO-8859-1` encoding. The second phase locates the <code>_charset_</code>
parameter and fixes the character encodings of the parameters as follows:
* All names of the parameters are re-encoded
- * The parameter values are re-encoded, unless the parameter value is an
uploaded file. Actually the parameter (not the files of course) are internally
as `byte[]({{ refs..path }})` where the conversion to a string is done on the
fly (and yes, the conversion using the `\*charset\*` character encoding is of
course cached for performance reasons)
+ * The parameter values are re-encoded, unless the parameter value is an
uploaded file. Actually the parameter (not the files of course) are internally
as `byte[]({{ refs..path }})` where the conversion to a string is done on the
fly (and yes, the conversion using the <code>_charset_</code> character
encoding is of course cached for performance reasons)
* If the parameter is an uploaded file, the file name is re-encoded on the
fly when accessed
<div class="info">
