https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
--- Comment #10 from Mark Thomas ---
I've patched trunk (9.0.x) to make the reason for the failure available as a
request attribute that the FailedRequestFilter can then use to provide a better
status code to the client.
I'll give it a few day
https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
--- Comment #11 from Mark Thomas ---
No objections were raised so I have back-ported this to 8.0.x (for 8.0.25
onwards) and 7.0.x (for 7.0.64 onwards). I have also proposed it for 6.0.x.
--
You are receiving this mail because:
You are the ass
https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
--- Comment #12 from Christopher L. Simons ---
Any objections to applying the attached documentation patch? I think it would
save many users from having to search and dig up this post to realize they can
use FailedRequestFilter to adjust the b
https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
Christopher L. Simons changed:
What|Removed |Added
Keywords||PatchAvailable
--
You are rec
https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
Christopher L. Simons changed:
What|Removed |Added
Target Milestone|- |default
Product|Tom
https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
Christopher L. Simons changed:
What|Removed |Added
CC||christopherleesimons@gmail.
https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
Christopher L. Simons changed:
What|Removed |Added
Attachment #32821|Initial draft of patch to |Initial draft of patch,
https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
--- Comment #1 from Christopher Schultz ---
I'm iffy on this patch because it's not configurable (I'd like to point out
that the current behavior is also not configurable, and this definitely is an
improvement). The application itself might wan
https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
--- Comment #2 from Mark Thomas ---
Agreed. The right response is definitely going to be application dependent.
Most of the problem stems from getParameterXXX() methods not declaring any
exceptions. We also run the risk of breaking lots of stuf
https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
Christopher L. Simons changed:
What|Removed |Added
Attachment #32821|0 |1
is obsolete|
https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
--- Comment #4 from Christopher L. Simons ---
(In reply to Christopher Schultz from comment #1)
> Look into how Globals.PARAMETER_PARSE_FAILED_ATTR is used to communicate
> this situation to the application and see if you can come up with somet
https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
--- Comment #5 from Mark Thomas ---
I was thinking a using the existing attribute to trigger a 400 response and a
new attribute to trigger a 413 response. That should cover all the current
possibilities for parameter/part issues.
Note RFC 2616
https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
--- Comment #6 from Konstantin Kolinko ---
(In reply to Christopher L. Simons from comment #4)
>
> Unconditionally sending a 400 from FailedRequestFilter upon failure seems
> incorrect as the HTTP spec states that 400 is to be used when the re
https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
--- Comment #7 from Konstantin Kolinko ---
(In reply to Mark Thomas from comment #5)
> I was thinking a using the existing attribute to trigger a 400 response and
> a new attribute to trigger a 413 response. That should cover all the current
>
https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
--- Comment #8 from Mark Thomas ---
(In reply to Konstantin Kolinko from comment #7)
> (In reply to Mark Thomas from comment #5)
> > I was thinking a using the existing attribute to trigger a 400 response and
> > a new attribute to trigger a 41
https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
--- Comment #9 from Christopher Schultz ---
I'd prefer being able to set the response code using an init-param. If we want
to keep the current behavior and add on to it, it seems we need a second
attribute to indicate the second condition. In e
https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
Mark Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Hi Mark,
2015-06-24 16:27 GMT+03:00 :
>
> https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
>
> --- Comment #10 from Mark Thomas ---
> I've patched trunk (9.0.x) to make the reason for the failure available
as a
> request attribute that the FailedRequestFilter can then use to provide a
better
On 24/06/2015 14:43, Violeta Georgieva wrote:
> Hi Mark,
>
> 2015-06-24 16:27 GMT+03:00 :
>>
>> https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
>>
>> --- Comment #10 from Mark Thomas ---
>> I've patched trunk (9.0.x) to make the reason for the failure available
> as a
>> request attribute th
Mark,
On 6/24/15 9:57 AM, Mark Thomas wrote:
> On 24/06/2015 14:43, Violeta Georgieva wrote:
>> Hi Mark,
>>
>> 2015-06-24 16:27 GMT+03:00 :
>>>
>>> https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
>>>
>>> --- Comment #10 from Mark Thomas ---
>>> I've patched trunk (9.0.x) to make the reason f
2015-06-24 18:37 GMT+03:00 Christopher Schultz :
>
> Mark,
>
> On 6/24/15 9:57 AM, Mark Thomas wrote:
> > On 24/06/2015 14:43, Violeta Georgieva wrote:
> >> Hi Mark,
> >>
> >> 2015-06-24 16:27 GMT+03:00 :
> >>>
> >>> https://bz.apache.org/bugzilla/show_bug.cgi?id=58031
> >>>
> >>> --- Comment #10 f
21 matches
Mail list logo
