You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2017/02/15 09:49:01 UTC
[Bug 60735] New: Multibytes characters in URL caused tomcat return
HTTP 400 after upgraded 7.0.67 to 7.0.75
https://bz.apache.org/bugzilla/show_bug.cgi?id=60735
Bug ID: 60735
Summary: Multibytes characters in URL caused tomcat return HTTP
400 after upgraded 7.0.67 to 7.0.75
Product: Tomcat 7
Version: 7.0.75
Hardware: PC
OS: Linux
Status: NEW
Severity: major
Priority: P2
Component: Connectors
Assignee: dev@tomcat.apache.org
Reporter: lovetide@qq.com
Target Milestone: ---
After upgraded tomcat from 7.0.67 to 7.0.75, if there're UTF8 encoded
characters in URL, tomcat will return "HTTP/1.1 400 Bad Request" now with or
without 'URIEncoding="UTF-8"' parameter in <Connector /> element. It works in
7.0.67.
Test:
$ curl -v localhost:8080/汉字/测试.html
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /汉字/测试.html HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< Server: Apache-Coyote/1.1
< Transfer-Encoding: chunked
< Date: Wed, 15 Feb 2017 09:27:53 GMT
< Connection: close
<
* Curl_http_done: called premature == 0
* Closing connection 0
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60735] Multibytes characters in URL caused tomcat return HTTP
400 after upgraded 7.0.67 to 7.0.75
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60735
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|NEW |RESOLVED
--- Comment #1 from Mark Thomas <ma...@apache.org> ---
The characters are invalid so the 400 response is correct. The validation of
request lines was tightened up as a result of CVE-2016-6816.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60735] Multibytes characters in URL caused tomcat return HTTP
400 after upgraded 7.0.67 to 7.0.75
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60735
--- Comment #2 from LiuYan 刘研 <lo...@qq.com> ---
(In reply to Mark Thomas from comment #1)
> The characters are invalid so the 400 response is correct. The validation of
> request lines was tightened up as a result of CVE-2016-6816.
Thanks for the quick response.
So, does this means 'URIEncoding' parameter is useless now and will be removed
in the future?
I actually like this convenient parameter, clear URL string without URL-encoded
is my favorite, and security isn't my first concern.
So it would be nice if 'URIEncoding parameter enabled' is configurable for both
security and convenience (disabled by default for security).
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60735] Multibytes characters in URL caused tomcat return HTTP
400 after upgraded 7.0.67 to 7.0.75
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60735
--- Comment #3 from Mark Thomas <ma...@apache.org> ---
(In reply to LiuYan 刘研 from comment #2)
> So, does this means 'URIEncoding' parameter is useless now and will be
> removed in the future?
No. URIEncoding determines how a correctly %-encoded URI is converted to
characters. To use UTF-8 characters that contain byte values that are not
permitted by the HTTP specification, the bytes for those characters will need
to be %-encoded.
> I actually like this convenient parameter, clear URL string without
> URL-encoded is my favorite
Unless there are some major changes to the HTTP specification, that is not
going to be possible.
Note: Some browsers allow you to use UTF-8 characters in the address bar and
will automatically convert them to the correct %-encoded form under the covers
as a convenience to users.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60735] Multibytes characters in URL caused tomcat return HTTP
400 after upgraded 7.0.67 to 7.0.75
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60735
--- Comment #7 from LiuYan 刘研 <lo...@qq.com> ---
(In reply to Michael Osipov from comment #5)
> (In reply to LiuYan 刘研 from comment #4)
> > Yes, I know firefox and w3m will encode URL, wget do that too. So I will
> > move from curl to wget to get correct response.
>
> Non-sense, curl does the right thing as long as your URL is valid. It does
> not validate the path of the URL.
I didn't blame "it's curl fault", I actually like curl: "send what I passed to
you, do not encode URL for me".
I move from curl to wget because I don't like encoded URL -- unfriendly to me &
size is fat/larger (size is 3 times of raw bytes sequence).
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60735] Multibytes characters in URL caused tomcat return HTTP
400 after upgraded 7.0.67 to 7.0.75
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60735
--- Comment #8 from LiuYan 刘研 <lo...@qq.com> ---
(In reply to Christopher Schultz from comment #6)
>
> Both Tomcat 8.0 and 8.5 reply with a 404 when I request /汉语/漢語.html within a
> test web application's context URL space where no such file exists.
>
> Something else must be wrong with the OP's environment.
If you use previous version (7.0.72 & 8.5.2 & 8.0.35 & 6.0.45 or lower version)
to test, then yes, you got HTTP 404. This is what I wanted/expected.
If you use latest version (7.0.75 & 8.5.11 & 8.0.41 & 4.0.48) to test, you will
get HTTP 400, as Mark Thomas said.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60735] Multibytes characters in URL caused tomcat return HTTP
400 after upgraded 7.0.67 to 7.0.75
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60735
--- Comment #5 from Michael Osipov <19...@gmx.net> ---
(In reply to LiuYan 刘研 from comment #4)
> Yes, I know firefox and w3m will encode URL, wget do that too. So I will
> move from curl to wget to get correct response.
Non-sense, curl does the right thing as long as your URL is valid. It does not
validate the path of the URL.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60735] Multibytes characters in URL caused tomcat return HTTP
400 after upgraded 7.0.67 to 7.0.75
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60735
--- Comment #6 from Christopher Schultz <ch...@christopherschultz.net> ---
(In reply to Michael Osipov from comment #5)
> (In reply to LiuYan 刘研 from comment #4)
> > Yes, I know firefox and w3m will encode URL, wget do that too. So I will
> > move from curl to wget to get correct response.
>
> Non-sense, curl does the right thing as long as your URL is valid. It does
> not validate the path of the URL.
+1
$ curl 'http://example.com/汉字/测试.html'
From my httpd access log:
x.y.z.184 - - [15/Feb/2017:14:08:20 -0500] "GET
/\xe6\xb1\x89\xe5\xad\x97/\xe6\xb5\x8b\xe8\xaf\x95.html HTTP/1.1" 404 480 "-"
"curl/7.51.0"
curl behaves correctly.
Both Tomcat 8.0 and 8.5 reply with a 404 when I request /汉语/漢語.html within a
test web application's context URL space where no such file exists.
Something else must be wrong with the OP's environment.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
[Bug 60735] Multibytes characters in URL caused tomcat return HTTP
400 after upgraded 7.0.67 to 7.0.75
Posted by bu...@apache.org.
https://bz.apache.org/bugzilla/show_bug.cgi?id=60735
--- Comment #4 from LiuYan 刘研 <lo...@qq.com> ---
(In reply to Mark Thomas from comment #3)
> No. URIEncoding determines how a correctly %-encoded URI is converted to
> characters. To use UTF-8 characters that contain byte values that are not
> permitted by the HTTP specification, the bytes for those characters will
> need to be %-encoded.
Okay, thanks!
I misunderstood it's purpose, thought it was used to encode/decode bytes
sequence of the requested URI string.
>
> Note: Some browsers allow you to use UTF-8 characters in the address bar and
> will automatically convert them to the correct %-encoded form under the
> covers as a convenience to users.
Yes, I know firefox and w3m will encode URL, wget do that too. So I will move
from curl to wget to get correct response.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org