On 05/09/2016 06:47, Greg Wilkins wrote:
>
> Stuart,
>
> +1 for RFC-3986
+1
> +0.5 for <default-encoding>, as I think that perhaps that should only
> apply to the response encoding. The server really only has control of
> the content it generates and it is the browsers and clients that control
> the encoding of requests.
The last time I checked (admittedly a while ago), browsers were pretty
poor at correctly providing the necessary encoding information with
request bodies.
> So even if they are both trending towards UTF-8, it may not be that they
> both should be switched at the same time for the same application and
> same browser population.
+1. My experience has been that this area is generally a mess so more
flexibility will be better than less in this case.
> Maybe <default-request-encoding> and <default-response-encoding>
> Actually we really don't need to say "default" as there will still be
> another default that is used when neither these elements are set.
>
> So they could just be <request-encoding> and <response-encoding>, with
> documentation that says that the encoding set by these is overridden by
> the programmatic methods: setCharacterEncoding, setContent-Type and/or
> setLocale.
+1.
Mark