https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #33 from Mark Thomas ---
Any further questions should be addressed to the users mailing list.
http://tomcat.apache.org/lists.html
--
You are receiving this mail because:
You are the assignee for the bug.
-
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #32 from sureshkarthi ---
(In reply to Mark Thomas from comment #27)
> (In reply to Markus Schlegel from comment #26)
> > The Patch provided in the attachments has a USE_URL_LIVING_STANDARD switch
> > implemented.
> > However, when
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #31 from sureshkarthiece ---
(In reply to Christopher Schultz from comment #15)
> (In reply to Trevor Robinson from comment #14)
> > This is not acceptable to be put into a bugfix version.
>
> Um... this should UN-BREAK things, not
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
Remy Maucherat changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
Ayoub changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #28 from Markus Schlegel ---
Have a 3 hours remote debugging session behind me, where we had to check why
our app is not working anymore on one specific server.
It turned out, that the server had a reverse-proxy (NGINX) in front of
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #27 from Mark Thomas ---
(In reply to Markus Schlegel from comment #26)
> The Patch provided in the attachments has a USE_URL_LIVING_STANDARD switch
> implemented.
> However, when I look at the source code of my downloaded Tomcat 8.
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #26 from Markus Schlegel ---
The Patch provided in the attachments has a USE_URL_LIVING_STANDARD switch
implemented.
However, when I look at the source code of my downloaded Tomcat 8.5.32, I can
not see this change (and my webapp us
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #25 from remmeier ---
no, just good to have that statement in terms of security for other people
because this thing here causes a gigantic amount of issues since it affects in
our case two dozen application with some beeing a bit la
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #24 from Christopher Schultz ---
(In reply to remmeier from comment #21)
> are there any security implications when relaxing a char like [ and ]?
> Because there are other specifications like JSON API making heavy use these
> two ch
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #23 from Remy Maucherat ---
(In reply to Matthew Davie from comment #22)
> Still unusable, tried a number of changes but still fails to work due to the
> RFC change. Makes Tomcat worthless to our current and future usage, surely
> t
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
Matthew Davie changed:
What|Removed |Added
Version|8.5.x-trunk |8.5.32
--- Comment #22 from Matthew Da
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #21 from remmeier ---
are there any security implications when relaxing a char like [ and ]?
Because there are other specifications like JSON API making heavy use these two
characters and if so, Tomcat just becomes no option anymore
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #20 from Mark Thomas ---
The status is:
- Browser behaviour is inconsistent between browsers
https://cwiki.apache.org/confluence/display/TOMCAT/Encoding+and+URIs
- Browser behaviour appears to be inconsistent with the spec the bro
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #19 from remmeier ---
what is now the conclusion of this topic? since the topic has been resolved(?).
The change is still breaking and not aligned with what the major browser
vendors do as far as I understand?
--
You are receiving
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #18 from Trevor Robinson ---
(In reply to Christopher Schultz from comment #15)
> Um... this should UN-BREAK things, not break things. I don't think you want
> to wait until Tomcat 10 for your brackets to start working again, do you
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
Mark Thomas changed:
What|Removed |Added
CC||remo.me...@adnovum.ch
--- Comment #17 fr
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
Mark Thomas changed:
What|Removed |Added
CC||matthewd@paprika-software.c
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #15 from Christopher Schultz ---
(In reply to Trevor Robinson from comment #14)
> This is not acceptable to be put into a bugfix version.
Um... this should UN-BREAK things, not break things. I don't think you want to
wait until Tom
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #14 from Trevor Robinson ---
This is not acceptable to be put into a bugfix version. We use square brackets
for tag filtering on query parameters, causing a lot of our queries to be
suddenly bounced back with a 400. Luckily this onl
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
Mark Thomas changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #12 from Mark Thomas ---
That wasn't my reading but it isn't the easiest spec to read. It is much closer
to an implementation description than a spec.
I decided to do some testing to see what the current behaviour is. Results
here:
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #11 from Remy Maucherat ---
Given the spec test, I thought the request target was a bit different, allowing
unencoded '\\', '|' and '^'.
Same conclusion for the query part.
--
You are receiving this mail because:
You are the assig
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #10 from Mark Thomas ---
I've been spending some time looking at whatwg.org URL spec. It appears, from
https://bugzilla.mozilla.org/show_bug.cgi?id=1451347 that the browsers consider
any string that passes the URL parser as valid an
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
Remy Maucherat changed:
What|Removed |Added
Attachment #35856|0 |1
is obsolete|
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #8 from Mark Thomas ---
>From memory, the previous parser was lenient to the extent that it only checked
for characters that were not permitted anywhere in the request target rather
than checking each part individually.
My initial
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #7 from Remy Maucherat ---
Created attachment 35856
--> https://bz.apache.org/bugzilla/attachment.cgi?id=35856&action=edit
HttpParser patch
According to my understanding on that URL spec wording, here's what the
HttpParser could
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
--- Comment #6 from Piotr Suwała ---
There is tomcat.util.http.parser.HttpParser.requestTargetAllow={|} for 8.5.x
but it was dropped for 9.0.x. However it ignores these characters possibly
everywhere.
There should be flag that just allows for
https://bz.apache.org/bugzilla/show_bug.cgi?id=62273
Remy Maucherat changed:
What|Removed |Added
Resolution|INVALID |---
OS|Mac OS X 10.1
29 matches
Mail list logo
