RE: Tomcat URL encoding

[Cai, Charles [COMRES/RTC/RTC]]

Sorry, I forgot mention, I already add the following to the catalina.properties 
file. 

org.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=true 

It didn't seems worked for me neither. 

Charles Cai | T +1 440 329 4888

-Original Message-
From: Rossen Stoyanchev [mailto:rstoyanc...@pivotal.io] 
Sent: Thursday, June 15, 2017 3:11 PM
To: Tomcat Users List 
Subject: Re: Tomcat URL encoding

You need to enable this through the ALLOW_BACKSLASH property:
https://tomcat.apache.org/tomcat-8.5-doc/config/systemprops.html

On Thu, Jun 15, 2017 at 2:44 PM, Cai, Charles [COMRES/RTC/RTC] < 
charles@emerson.com> wrote:

> Hi Guys,
>
> Looking for help here after search on the web for couple hours:
>
> I'm currently doing some testing on Tomcat 8.5.9   I'm trying to encode
> all the URL that is requesting to my server.
> One thing I have noticed it wasn't working is the `\` (back slash) 
> can't be allowed in the URL.
>
> I'm getting the error saying:
> INFO [https-jsse-nio-8443-exec-10] 
> org.apache.coyote.http11.Http11Processor.service
> 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
>
> The test requesting URL is like this:
> https://localhost:8443/passthrough.jsp?ntUserName=comany\testuser
>
> Currenty, I tried those two approachs:
> 1st, set the server.xml with URIEncoding:
> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html
>
> 2nd, add the following filter:
> https://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q1
>
> It should be like this after the encoding (replace `\` with `%5C` ) :
> https://localhost:8443/passthrough.jsp?ntUserName=comany%5Ctestuser
>
> but none of those options worked for me.
>
> Thank you
>
> Charles Cai
>
>

Re: Tomcat URL encoding

[Mark Thomas]

On 15/06/2017 14:44, Cai, Charles [COMRES/RTC/RTC] wrote:

Hi Guys,

Looking for help here after search on the web for couple hours:

I'm currently doing some testing on Tomcat 8.5.9   I'm trying to encode all the 
URL that is requesting to my server.
One thing I have noticed it wasn't working is the `\` (back slash) can't be 
allowed in the URL.

I'm getting the error saying:
INFO [https-jsse-nio-8443-exec-10] 
org.apache.coyote.http11.Http11Processor.service 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

The test requesting URL is like this:
https://localhost:8443/passthrough.jsp?ntUserName=comany\testuser

Currenty, I tried those two approachs:
1st, set the server.xml with URIEncoding:
http://tomcat.apache.org/tomcat-7.0-doc/config/http.html

2nd, add the following filter:
https://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q1

It should be like this after the encoding (replace `\` with `%5C` ) :
https://localhost:8443/passthrough.jsp?ntUserName=comany%5Ctestuser

but none of those options worked for me.


It needs to be encoded on the client.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat URL encoding

[Rossen Stoyanchev]

You need to enable this through the ALLOW_BACKSLASH property:
https://tomcat.apache.org/tomcat-8.5-doc/config/systemprops.html

On Thu, Jun 15, 2017 at 2:44 PM, Cai, Charles [COMRES/RTC/RTC] <
charles@emerson.com> wrote:

> Hi Guys,
>
> Looking for help here after search on the web for couple hours:
>
> I'm currently doing some testing on Tomcat 8.5.9   I'm trying to encode
> all the URL that is requesting to my server.
> One thing I have noticed it wasn't working is the `\` (back slash) can't
> be allowed in the URL.
>
> I'm getting the error saying:
> INFO [https-jsse-nio-8443-exec-10] 
> org.apache.coyote.http11.Http11Processor.service
> 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
>
> The test requesting URL is like this:
> https://localhost:8443/passthrough.jsp?ntUserName=comany\testuser
>
> Currenty, I tried those two approachs:
> 1st, set the server.xml with URIEncoding:
> http://tomcat.apache.org/tomcat-7.0-doc/config/http.html
>
> 2nd, add the following filter:
> https://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q1
>
> It should be like this after the encoding (replace `\` with `%5C` ) :
> https://localhost:8443/passthrough.jsp?ntUserName=comany%5Ctestuser
>
> but none of those options worked for me.
>
> Thank you
>
> Charles Cai
>
>

Tomcat URL encoding

[Cai, Charles [COMRES/RTC/RTC]]

Hi Guys,

Looking for help here after search on the web for couple hours:

I'm currently doing some testing on Tomcat 8.5.9   I'm trying to encode all the 
URL that is requesting to my server.
One thing I have noticed it wasn't working is the `\` (back slash) can't be 
allowed in the URL.

I'm getting the error saying:
INFO [https-jsse-nio-8443-exec-10] 
org.apache.coyote.http11.Http11Processor.service 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

The test requesting URL is like this:
https://localhost:8443/passthrough.jsp?ntUserName=comany\testuser

Currenty, I tried those two approachs:
1st, set the server.xml with URIEncoding:
http://tomcat.apache.org/tomcat-7.0-doc/config/http.html

2nd, add the following filter:
https://wiki.apache.org/tomcat/FAQ/CharacterEncoding#Q1

It should be like this after the encoding (replace `\` with `%5C` ) :
https://localhost:8443/passthrough.jsp?ntUserName=comany%5Ctestuser

but none of those options worked for me.

Thank you

Charles Cai

Re: tomcat 7, null tag attributes

[Coty Sutherland]

On Wed, Jun 14, 2017 at 2:33 PM, Christopher Schultz
 wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Chris,
>
> On 6/14/17 10:17 AM, Chris Cheshire wrote:
>> On Tue, Jun 13, 2017 at 6:06 PM, Mark Thomas 
>> wrote:
>>
>>> On 13/06/17 22:01, Mark Thomas wrote:
 On 13/06/17 15:27, Chris Cheshire wrote:
>>>
>>> 
>>>
> I'm bewildered at why tomcat operates this way when it comes
> to Numbers
>>> and
> Strings. Why is it insistent on coercion when null and zero
> are
>>> absolutely
> not the same value.  If this is because of autoboxing, then
> isn't that a bug? A long is not a Long, and when tag
> attributes must be objects and
>>> not
> atomic types, shouldn't they be treated accordingly?

 Tomcat behaves this way because the specification says it has
 to. Plenty of folks disagree strongly with the specification
 but Tomcat has to implement it. COERCE_TO_ZERO is a
 specification breaking configuration option to workaround this
 particular behaviour.

 I've been digging in to this some more and it appears that
 COERCE_TO_ZERO has been given a wider scope in later versions
 of Tomcat. The test case you present above behaves the way you
 want with COERCE_TO_ZERO set to false in 8.0.x and above. I
 need to dig into why that wider scope wasn't applied to 7.0.x.
>>>
>>> Mystery solved thanks to some svn archaeology and
>>> cross-referencing to the relevant specs.
>>>
>>> Tomcat 7 implements EL 2.2. EL 2.2 requires coercion of "" and
>>> null to 0 for numeric types (section 1.18.3). (As did earlier
>>> versions of the EL spec).
>>>
>>> Initially there weren't many complaints because the coercion
>>> rules weren't implemented correctly in one important case (i.e.
>>> they left these as null rather than coercing to zero). Then bug
>>> 43285 [1] got fixed and the complaints started.
>>>
>>> To address the complaints, Tomcat introduced the system property
>>> org.apache.el.parser.COERCE_TO_ZERO which restored the
>>> non-specification compliant behaviour for the one coercion case
>>> that was causing problems. To align with the EL 2.2.
>>> specification, the default was for coercion to zero to occur.
>>>
>>> The level of complaints about the coercion rules was such that a
>>> backwards compatible change was introduced in EL 3.0 to not
>>> coerce to zero. Given Java EE's normal approach that backwards
>>> compatibility concerns trump all others, it is a sign of the
>>> seriousness with which the issue was taken that an incompatible
>>> change was made.
>>>
>>> Tomcat 8, which implemented EL 3.0, switched to the new coercion
>>> rules. To help migration of 7.0.x applications, the role of
>>> COERCE_TO_ZERO was expanded to cover all instances of EL
>>> coercion. To align with EL 3.0, the default was changed not to
>>> coerce to zero.
>>>
>>> Which brings us to where we are today.
>>>
>>> The problem you are seeing is a spec compliant coercion that is
>>> not covered by the COERCE_TO_ZERO property in 7.0.x.
>>>
>>> There are several possible solutions:
>>>
>>> 1. Upgrade to 8.x (8.5.x recommended in preference to 8.0.x) I
>>> appreciate that an RPM is not available for Tomcat 8 but 8.0.x
>>> has had stable releases for three years and 8.5.x for 1 year.
>>>
>>> 2. Use one of the workarounds. All pretty ugly.
>>>
>>> 3. Lobby for the extension of scope for COERCE_TO_ZERO in 7.0.x
>>> to be equivalent to the scope in 8.0.x. At this stage in the
>>> 7.0.x that is unlikely to happen. The risk of breakage for other
>>> users is too great.
>>>
>>> 4. Lobby for an additional configuration option for 7.0.x that
>>> extends the of scope for COERCE_TO_ZERO in 7.0.x to be equivalent
>>> to the scope in 8.0.x. This should be doable with care (there was
>>> some refactoring involved in the scope change that would need
>>> careful back-porting). This is also dependent on the CentOS
>>> distribution picking up the change to 7.0.x. I don't know how
>>> likely that is. Given the current package is based on a version
>>> over a year old I suspect that the changes of this being quick
>>> are very low.
>>>
>>> None of those options look ideal. I'd probably go with 1 but my
>>> familiarity with Tomcat is such that I usually prefer to work
>>> with an ASF distribution rather than a downstream one anyway.
>>> YMMV.
>>>
>>> Mark
>>>
>>>
>>> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=43285
>>>
>>>
>>>
>> Mark,
>>
>> Thanks for the investigation into this.
>>
>> You are right in that (1) is the best option. Finding time to
>> translate the ASF distribution into one with appropriate run
>> scripts and configs, along with a mechanism for in-place updating
>> is tough. Having RPMs for that saves me a lot of time which is why
>> I stuck with 7.x for so long. In the meantime I'll figure out the
>> cleanest ugly workaround I can. I definitely won't lobby for any
>> non-security fixes in a product