Bug 43914 - HTTP spec violation when generating HTTP redirects for folders without trailing slash
HTTP spec violation when generating HTTP redirects for folders without traili...
Status: RESOLVED FIXED
Product: Tomcat 5
Classification: Unclassified
Component: Connector:Coyote
5.5.25
All All
: P2 normal (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2007-11-20 05:53 UTC by Ivan Todoroski
Modified: 2008-01-06 15:16 UTC (History)
0 users



Attachments
minimal webapp that demonstrates the problem (608 bytes, application/octet-stream)
2007-11-20 05:54 UTC, Ivan Todoroski
Details
simple fix (1.87 KB, patch)
2007-11-20 05:57 UTC, Ivan Todoroski
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Ivan Todoroski 2007-11-20 05:53:53 UTC
Copy the attached static.war into $CATALINA_HOME/webapps. Then start the server 
and paste this HTTP request in netcat:

GET /static/name%20with%20spaces HTTP/1.1
User-Agent: Jakarta Commons-HttpClient/3.0
Host: localhost:8080

Tomcat will answer with the following HTTP redirect:

HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
Location: http://localhost:8080/static/name with spaces/
Transfer-Encoding: chunked
Date: Tue, 20 Nov 2007 13:46:12 GMT

Observe the Location: header. It has raw unencoded spaces in the URL which is 
in clear violation of the HTTP specification.
Comment 1 Ivan Todoroski 2007-11-20 05:54:34 UTC
Created attachment 21160 [details]
minimal webapp that demonstrates the problem
Comment 2 Ivan Todoroski 2007-11-20 05:57:38 UTC
Created attachment 21161 [details]
simple fix

I have no idea what the preferred internal Tomcat method for encoding URLs is,
I just copied the URLEncoder stuff from DefaultServlet.
Comment 3 Mark Thomas 2007-12-24 11:03:17 UTC
I have been through RFC2616 and can't see anywhere that states that the location
header for a 302 must be encoded. Please provide reference(s) to the section(s)
that require this.
Comment 4 Ivan Todoroski 2007-12-25 21:23:45 UTC
Section 14.30 of RFC2616 specifies the Location header as:

   Location       = "Location" ":" absoluteURI

Then, in section 3.2.1 it specifies the definition of absoluteURI:

   For definitive information on
   URL syntax and semantics, see "Uniform Resource Identifiers (URI):
   Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs
   1738 [4] and RFC 1808 [11]). This specification adopts the
   definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
   "host","abs_path", "rel_path", and "authority" from that
   specification.

Moving on to RFC2396, in section 3 you can find the start of the absoluteURI 
BNF. If you follow the production you will eventually see that the basic 
characters of the individual path components come down to this:

      pchar         = unreserved | escaped |
                      ":" | "@" | "&" | "=" | "+" | "$" | ","

Basically, the above says it can only contain unreserved characters and the 
characters explicitly specified, all the rest must be escaped.

Look into sections 2.3 and 2.4.1 for the exact definitions of "unreserved" and 
"escaped", and you will see that none of them include the space character, 
which means "pchar" doesn't include it, which in turn means "absoluteURI" 
doesn't include it, which means eventually that the Location header can't 
include it either. Same goes for many other special characters not explicitly 
covered by "pchar", not just space.
Comment 5 Mark Thomas 2007-12-26 13:25:35 UTC
Thanks for the pointer. That makes perfect sense.

I have applied your patch to trunk and proposed it for 6.0.x and 5.5.x
Comment 6 Mark Thomas 2007-12-28 13:08:30 UTC
Fixed in Tomcat 6.0.x.
Comment 7 Mark Thomas 2008-01-06 15:16:55 UTC
Fixed in 5.5.x and will be included in 5.5.26 onwards.