Hi,
Recently we had a bug report at Apache Wicket about this problem [1] - when
the user agent sends a request with wrong URL encoding (in the query
string) then Wicket throws an exception which was not easy to be handled by
the application. The exception was 1) logged by the web container and 2)
2013/3/2 Mark Thomas :
>
>> 3. I remember discussions on the mailing lists regarding whether it is
>> possible to make uri-encoding to be webapp-specific setting.
>
> That is never going to be possible because decoding has to happen before
> mapping.
>
My idea roughly is
1. Let Mapper operate on b
On 01/03/2013 22:44, Remy Maucherat wrote:
> About endOfInput, I wouldn't use it. The only place where it is somewhat
> useful is the URI conversion, which can check the underflow flag and
> throw an exception. Especially if you also want to have "perfect" body
> decoding, you'll have to use that f
On 01/03/2013 22:39, Konstantin Kolinko wrote:
> 1. I have not tested, but as proposed rejection happens in
> CoyoteAdapter, I think it will happen too early for ErrorReportValve
> to work.
>
> As such, a user will receive a response that consists of HTTP status
> line only, which browsers disp
On Fri, 2013-03-01 at 20:36 +, Mark Thomas wrote:
> I expect to have a similar discussion about request bodies once URIs are
> resolved where I have essentially the same view - a decoding error
> should lead to a request failure.
>
> Thoughts?
It may not be useful. UTF-8 is THE most used en
2013/3/2 Mark Thomas :
> Due to bug 54602 [1] I have been writing some test cases to examine how we
> handle invalid bytes sequences in URIs.
>
> My expectation was:
> - valid byte sequence for expected encoding -> 200 (assuming no other
> problems)
> - invalid byte sequence for expected encoding
