On 13/10/2017 07:38, Peter Kreuser wrote:
> Chris,
>
>
>
>
> Peter Kreuser
>> Am 13.10.2017 um 04:29 schrieb Christopher Schultz
>> <w...@christopherschultz.net>:
>>
> James,
>
>>>> On 10/12/17 8:44 PM, James H. H. Lampert wrote:
>>>> Question:
>>>>
>>>> The application we're developing has a suite of web services
>>>> (RESTful, Swagger-based), and at least one of them can accept a
>>>> pound sign ("#") as a URL parameter.
>>>>
>>>> Several months ago, with the application and all of its services
>>>> running on Tomcat 7, it was accepting a plain, naked # in the URL.
>>>> Now, running on Tomcat 8.5, it's returning an error message
>>>> ("HTTP/1.1 400").
>
> No client should ever send a naked # to a server. It's a violation of
> the spec, full stop. That isn't to say that Tomcat should fail in any
> particular way, but Tomcat is well within its rights to say "a # is
> not allowed in a URL, so this is a bad request".
>
>
>> Nevertheless there is AFAIR a commandline switch to set TC 8.5 to the old
>> behavior.
>From memory, # isn't one of the allowed exceptions.
The full list of invalid characters in the request line that Tomcat
started to check for is:
' ', '\"', '#', '<', '>', '\\', '^', '`', '{', '|', '}'
The allowed exceptions are (currently) '{', '|', '}'
Mark
>> James, please browse the mail archives.
>> From a quick look this seems to help, for a short term solution:
>
>> https://marc.info/?l=tomcat-user&m=150183715500537&w=2
>
>> Please nevertheless fix the client, for a better world as Chris pointed out
>> ;-P.
>
>> Best regards
>
>> Peter
>
>>>> The developer (in a different time zone) has explained about
>>>> URL-encoding, but hasn't said whether there was anything in his
>>>> code to make it stop tolerating the naked # sign.
>>>>
>>>> Did the change from Tomcat 7 to Tomcat 8.5 have anything to do
>>>> with this?
>
> Each version of Tomcat gets more and more strict about the garbage it
> will accept from clients. This is done to improve the world as a
> whole, and also improve security when it comes to things like
> converting URL paths into filesystem paths, etc. Strictly speaking,
> everything should *always* be safe, but it helps to stop The Badness
> at the earliest opportunity.
>
>>>> And if so, are there any other common ASCII characters that used
>>>> to be accepted as characters, but now have to be URL-encoded?
> Anything in the URL spec that is allowed should be allowed. Clients
> should expect that anything not mentioned in the spec would be
> rejected by a compliant server.
>
> -chris
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
