>>>>> On Fri, 31 Mar 2017 15:07:40 +0100, Mark Thomas <markt_at_apache.org> said:
[...]
MT> -1. This is logically flawed.
MT> You can not have per web application definitions of URI encoding. It has
MT> to be container wide.
MT> Web applications are identified by matching the decoded URI to the
MT> longest matching context path.
MT> The request URI must be decoded before this match occurs.
MT> The encoding to use to do the decoding must be selected before the
MT> decoding takes place.
MT> Therefore, the encoding to use has to be selected before the correct web
MT> application has been identified.
>>>>> On Sat, 1 Apr 2017 08:50:30 +1100, Greg Wilkins <gregw_at_webtide.com> said:
GW> Very good point!
GW> I agree this makes webapp specific encodings nigh impossible to implement
GW> generally. Counter proposal is simple and clear.
This is a great point. You are correct.
MT> Additionally, my expectation is that nearly all applications will want
MT> to use UTF-8 for the URI but may have a range of preferences for default
MT> request/response encoding.
MT> My counter proposal is:
MT> - leave request-character-encoding as currently drafted
MT> - define the default URI encoding as UTF-8
MT> - make clear that containers may provide container specific mechanisms
MT> to change the default URI encoding or to provide more complex schemes
MT> such as use of a different encoding for the query string.
I agree with your counter proposal. Furthermore, I propose specifying
your counter proposal by adding the following text to the end of the
first paragraph in section "12.1 Use of URL Paths".
The request URL is decoded as a UTF-8 encoded string. Implementations
may provide container vendor specific configuration to change this
encoding or enable more fine-grained encoding such as using a
different encoding for the path and query string.
Thanks for your feedback on this one.
I'm going to write this one up as above.
ACTION: If you have any other issues, please let me know by start of
business Friday 14 April 2017.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 7 business days until planned start of Servlet 4.0 Public Review