https://issues.apache.org/bugzilla/show_bug.cgi?id=50065
Artem Anisimov <aanisi...@inbox.ru> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P2 |P4
--- Comment #2 from Artem Anisimov <aanisi...@inbox.ru> 2010-10-10 03:03:46 EDT
---
(In reply to comment #1)
> So where in the RFCs or EE specs can you find justification for the behavior
> you wish to see versus the behavior Tomcat exhibits?
>
> To quote from section 14.17 of RFC 2616:
>
> "The Content-Type entity-header field indicates the media type of the
> entity-body sent to the recipient"
>
> Note the reference to the entity-body; it says nothing about the parameters on
> the URI - which are interpreted as ISO-8859-1, since there is no standard to
> allow URIs in other character sets.
Javadoc for java.net.URLEncoder makes reference to
http://www.w3.org/TR/html40/appendix/notes.html#non-ascii-chars and says that
its preferable to utf-8 instead of iso-8859-1. I believe that utf-8 is a more
reasonable default choice than iso-8859-1 is.
Secondly, javadoc for HttpServletRequest::setRequestEncoding() seems
ambiguous to me. It indeed mentions only the request body, but it also says
"prior to reading request parameters or reading input". This "prior to reading
request parameters" can, of course, be an implementation detail, but to me it
seems reasonable to think that parameter decoding is influenced by choice of
the request encoding.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
