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