https://bz.apache.org/bugzilla/show_bug.cgi?id=60594

            Bug ID: 60594
           Summary: RFC 7230/3986 url requirement that prevents unencoded
                    curly braces should be optional, since it breaks
                    existing sites
           Product: Tomcat 7
           Version: 7.0.73
          Hardware: All
                OS: All
            Status: NEW
          Severity: regression
          Priority: P2
         Component: Connectors
          Assignee: dev@tomcat.apache.org
          Reporter: gros...@versifit.com
  Target Milestone: ---

Using the protocol="HTTP/1.1" connector (Coyote)

After upgrading a site to Tomcat 7.0.73 from 7.0.72 or from anything earlier, a
url with an unencoded { or } (ie. http://my.com?filter={"search":"isvalid"} ),
now returns a 400 error code and logs the following error message:

"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 valid characters are defined in RFC 7230 and RFC 3986"

Resolution:
Since this is a breaking change (aka regression failure), there should be an
option to override and turn this off (still reporting the first occurrence as
shown above), so that any existing site which experiences this can choose to
ignore this failure and continue as before, so they can deal with changing
their application at a later date, if they deem the security risk is
appropriate.

Defaulting the option to true (to enable the check) is perfectly fine, as long
as there is an option in a server and/or application config file to disable it,
and proper documentation on it.

Either this, or you clearly state in the release notes of 7.0.73, exactly what
will break, and recommend that users do not perform the Tomcat update, if they
are not ready to change their applications to comply, but I think this would
open up an even bigger can of worms.

Instead of just saying:
"Add additional checks for valid characters to the HTTP request line parsing so
invalid request lines are rejected sooner. (markt)" - this tells us nothing
about the impending doom we may face.

But, I would recommend just giving us the option to decide for ourselves.

-- 
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to