-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Mark,
On 10/18/18 09:09, Mark H. Wood wrote:
> On Thu, Oct 18, 2018 at 11:55:24AM +0100, M. Manna wrote:
>> Thanks a bunch Mark.
>>
>> "The correct fix is to ensure that the user agents are sending
>> specification compliant requests." - Do you me
On Thu, 18 Oct 2018 at 13:38, Mark Thomas wrote:
> On 18/10/18 12:17, Johan Compagner wrote:
> > how is the browser to blame for "
> > defaultMessageType=true&locale=en_US&action=[key:label.edit]"
> >
> > that url is not generated by a browser but by some software that uses a
> > browser...
>
> B
We already know that the parameter is the issue. Having to change all the
parameter i.e. refactoring code is always the answer.
The question was more about the recommended way of handling this issue
without exposing application to any specific vulnerability. I believe Mark
T has answered this alrea
On Thu, Oct 18, 2018 at 11:55:24AM +0100, M. Manna wrote:
> Thanks a bunch Mark.
>
> "The correct fix is to ensure that the user agents are sending
> specification compliant requests." - Do you mean at browser level ? If so,
> is there any specific browser/update we can use? We've checked a few
>
On 18/10/18 12:17, Johan Compagner wrote:
> how is the browser to blame for "
> defaultMessageType=true&locale=en_US&action=[key:label.edit]"
>
> that url is not generated by a browser but by some software that uses a
> browser...
Browsers these days try to be helpful and show the user the un-enc
I understand. We will use the connector patch for now. But thanks again for
sharing your thoughts. And the link to apache Confluence is really helpful!
Thanks,
On Thu, 18 Oct 2018 at 12:12, Mark Thomas wrote:
> On 18/10/18 11:55, M. Manna wrote:
> > Thanks a bunch Mark.
> >
> > "The correct fix
how is the browser to blame for "
defaultMessageType=true&locale=en_US&action=[key:label.edit]"
that url is not generated by a browser but by some software that uses a
browser...
On Thu, 18 Oct 2018 at 12:55, M. Manna wrote:
> Thanks a bunch Mark.
>
> "The correct fix is to ensure that the use
On 18/10/18 11:55, M. Manna wrote:
> Thanks a bunch Mark.
>
> "The correct fix is to ensure that the user agents are sending
> specification compliant requests." - Do you mean at browser level ? If so,
> is there any specific browser/update we can use? We've checked a few
> browsers so far (Firefo
Thanks a bunch Mark.
"The correct fix is to ensure that the user agents are sending
specification compliant requests." - Do you mean at browser level ? If so,
is there any specific browser/update we can use? We've checked a few
browsers so far (Firefox, Edge, Chrome) and none of them seem to have
On 18/10/18 09:52, M. Manna wrote:
> Hello,
>
> We received in error in our application after we have upgraded to 8.5.34
>
> INFO: Error parsing HTTP request header
> Note: further occurrences of HTTP header parsing errors will be logged at
> DEBUG level.
> java.lang.IllegalArgumentException: Inv
Hello,
We received in error in our application after we have upgraded to 8.5.34
INFO: Error parsing HTTP request header
Note: further occurrences of HTTP header parsing errors will be logged at
DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in the request
target. The val
11 matches
Mail list logo
