Re: URL-encoding and "#"

2017-10-15 Thread Alex O'Ree
What was unexpected for me, was that even if the the symbol is URL
encoded, it was still stripped out by tomcat. I understand now
allowing a backslash in a URL, however if it is URL encoded as
%5C then why not allow it? Maybe I'm missing something

On Fri, Oct 13, 2017 at 7:17 AM, i...@flyingfischer.ch
<i...@flyingfischer.ch> wrote:
> Am 13.10.2017 um 12:48 schrieb Alex O'Ree:
>> Well that explains a lot. Similar issue for me. With url encoding,  tomcat
>> is dropping back slash and the plus symbol.
>
> While I think it is perfectly eligible to strive for a most perfect
> alignement with standards and specs, I think Tomcat should allow a
> reasonnable set of characters to be optionally allowed (as they already
> are in Tomcat up to 8.5).
>
> I am aware that these options may be a security issue and that the
> documentation should state that clearly. However it is not always
> possible to correct the environment to be "standard" compatible and the
> educational approach by not allowing these options is understandable but
> may be not appropriate in many situations.
>
> Best regards
> Markus
>
> -
> 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



Re: URL-encoding and "#"

2017-10-13 Thread Mark Thomas
On 13/10/17 18:42, André Warnier (tomcat) wrote:
> On 13.10.2017 19:29, Mark Thomas wrote:
>> On 13/10/2017 18:15, André Warnier (tomcat) wrote:
>>> On 13.10.2017 18:17, Mark Thomas wrote:
 On 13/10/2017 17:09, James H. H. Lampert wrote:
> Thanks to all of you who responded.
>
> I found a web page that explains it in ways that I can wrap my
> 55-year-old brain around, and has an easy-to-read reference chart.
>
> https://perishablepress.com/stop-using-unsafe-characters-in-urls/
>
> Question: the problem first showed up on a web service that takes a
> "bodyless" POST operation, and I assume it also applies to GET
> operations, and to the URL portion of a POST with a body.
>
> But what about the body of a POST?

   From an HTTP specification point of view, anything goes.
>>>
>>> With respect, I believe that "anything goes" is a bit imprecise here.
>>
>> Nope.
>>
>> You can POST anything. You are talking specifically about form data.
> 
> Mmm. You are being a bit casuistic here. (Granted, not that I wasn't.)

Yeah, sorry about that. I tend to read "With respect..." as meaning
pretty much exactly the opposite.

> In the real world, I would expect that 99% of what is ever POSTed, /is/
> form data.
> Not you ?

For Tomcat I don't have a clue what the split is but my guess is that is
it a lot less than 99% these days.

>  In
>> that case, as I said, the body has to conform to what the component
>> processing it expects.
> 
> And that component would be .. ?

https://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/http/Parameters.java?view=annotate

> I don't really know, but I would guess that in most webservers, the
> component parsing the body of a POST with Content-type =
> application/x-www-form-urlencoded, may be the same as the one which is
> parsing the query-string of a URI, no ?
> Considering the similarity of these two things, it would seem that the
> temptation would be hard to resist.

Tomcat uses exactly the same code - with a little wrapping to get the
data into the same format before it starts.

Mark


>> And yes, unicode in form data is 'interesting'...
>>
>> Mark
>>
>>
>>> See e.g. https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4
>>>
>>> There are 2 ways for a user agent to send the content of a HTTP POST :
>>> 1) with Content-type header = application/x-www-form-urlencoded
>>> or
>>> 2) with Content-type header = multipart/form-data
>>>
>>> and while it is true that in the case (2), any submitted key=value pair
>>> would be sent separately 'as is', this would not necessarily be so in
>>> case (1), because then all key=value pairs would be concatenated into
>>> one long string, in which the different key=value pairs would be
>>> separated by (unescaped) "&" signs.
>>> (Apart from other required encodings, see the page above)
>>> So if the client is not a browser, and "composes" itself the POST body
>>> before sending it, and sends it with a Content-type (1), it had better
>>> encode the individual parameter pairs as described, before concatenating
>>> them, because that is what the server would expect.
>>>
>>> As an additional note, if it so happened that the data in the client
>>> could contain Unicode text, do not forget that this is (still) not the
>>> standard in HTTP (and URI's, and thus query-string-like things), and
>>> make sure that you use the proper method to encode any printable
>>> characters which are not purely US-ASCII.  Again, browsers generally do
>>> this correctly, but custom clients not necessarily. (And a "custom
>>> client" in this case, could even be a bit of javascript which is
>>> embedded in one of your own pages, but does its own calls to the server
>>> on the side).
>>>
>>> I just recently got bitten by this, even in a quite recent browser,
>>> where some javascript function was composing a POST to a server (using
>>> type (1) above), and was NOT doing it correctly, even though the page
>>> containing and calling this function was itself declared as
>>> Unicode/UTF-8.
>>> (that was with (and I am too sorely tempted to add "of course" to resist
>>> it) some revision of IE-11 - although other revisions of the same
>>> browser did not exhibit that same issue).
>>>
>>> [...]
>>>
>>>
>>> -
>>> 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
>>
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


-
To unsubscribe, 

Re: URL-encoding and "#"

2017-10-13 Thread James H. H. Lampert

On 10/13/17, 10:50 AM, Igal @ Lucee.org wrote:

On 10/13/2017 10:42 AM, André Warnier (tomcat) wrote:

Mmm. You are being a bit casuistic here. (Granted, not that I wasn't.)
In the real world, I would expect that 99% of what is ever POSTed,
/is/ form data.
Not you ?


10 years ago I would have agreed, but with REST services there are many
APIs that expect POSTed data that does not originate in web forms.


Exactly. And this whole discussion has been about RESTful web services 
(specifically, RESTful web services implemented with Swagger), so form 
data isn't even a consideration (and I'm pretty sure I plugged any 
Swagger-specific or JSON-specific holes in the body encoding months ago).



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



Re: URL-encoding and "#"

2017-10-13 Thread Igal @ Lucee.org

On 10/13/2017 10:42 AM, André Warnier (tomcat) wrote:

Mmm. You are being a bit casuistic here. (Granted, not that I wasn't.)
In the real world, I would expect that 99% of what is ever POSTed, 
/is/ form data.

Not you ?


10 years ago I would have agreed, but with REST services there are many 
APIs that expect POSTed data that does not originate in web forms.


Respectfully,

Igal Sapir
Lucee Core Developer
Lucee.org 



Re: URL-encoding and "#"

2017-10-13 Thread tomcat

On 13.10.2017 19:29, Mark Thomas wrote:

On 13/10/2017 18:15, André Warnier (tomcat) wrote:

On 13.10.2017 18:17, Mark Thomas wrote:

On 13/10/2017 17:09, James H. H. Lampert wrote:

Thanks to all of you who responded.

I found a web page that explains it in ways that I can wrap my
55-year-old brain around, and has an easy-to-read reference chart.

https://perishablepress.com/stop-using-unsafe-characters-in-urls/

Question: the problem first showed up on a web service that takes a
"bodyless" POST operation, and I assume it also applies to GET
operations, and to the URL portion of a POST with a body.

But what about the body of a POST?


  From an HTTP specification point of view, anything goes.


With respect, I believe that "anything goes" is a bit imprecise here.


Nope.

You can POST anything. You are talking specifically about form data.


Mmm. You are being a bit casuistic here. (Granted, not that I wasn't.)
In the real world, I would expect that 99% of what is ever POSTed, /is/ form 
data.
Not you ?

 In

that case, as I said, the body has to conform to what the component
processing it expects.


And that component would be .. ?
I don't really know, but I would guess that in most webservers, the component parsing the 
body of a POST with Content-type = application/x-www-form-urlencoded, may be the same as 
the one which is parsing the query-string of a URI, no ?
Considering the similarity of these two things, it would seem that the temptation would be 
hard to resist.




And yes, unicode in form data is 'interesting'...

Mark



See e.g. https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4

There are 2 ways for a user agent to send the content of a HTTP POST :
1) with Content-type header = application/x-www-form-urlencoded
or
2) with Content-type header = multipart/form-data

and while it is true that in the case (2), any submitted key=value pair
would be sent separately 'as is', this would not necessarily be so in
case (1), because then all key=value pairs would be concatenated into
one long string, in which the different key=value pairs would be
separated by (unescaped) "&" signs.
(Apart from other required encodings, see the page above)
So if the client is not a browser, and "composes" itself the POST body
before sending it, and sends it with a Content-type (1), it had better
encode the individual parameter pairs as described, before concatenating
them, because that is what the server would expect.

As an additional note, if it so happened that the data in the client
could contain Unicode text, do not forget that this is (still) not the
standard in HTTP (and URI's, and thus query-string-like things), and
make sure that you use the proper method to encode any printable
characters which are not purely US-ASCII.  Again, browsers generally do
this correctly, but custom clients not necessarily. (And a "custom
client" in this case, could even be a bit of javascript which is
embedded in one of your own pages, but does its own calls to the server
on the side).

I just recently got bitten by this, even in a quite recent browser,
where some javascript function was composing a POST to a server (using
type (1) above), and was NOT doing it correctly, even though the page
containing and calling this function was itself declared as Unicode/UTF-8.
(that was with (and I am too sorely tempted to add "of course" to resist
it) some revision of IE-11 - although other revisions of the same
browser did not exhibit that same issue).

[...]


-
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




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



Re: URL-encoding and "#"

2017-10-13 Thread Mark Thomas
On 13/10/2017 18:15, André Warnier (tomcat) wrote:
> On 13.10.2017 18:17, Mark Thomas wrote:
>> On 13/10/2017 17:09, James H. H. Lampert wrote:
>>> Thanks to all of you who responded.
>>>
>>> I found a web page that explains it in ways that I can wrap my
>>> 55-year-old brain around, and has an easy-to-read reference chart.
>>>
>>> https://perishablepress.com/stop-using-unsafe-characters-in-urls/
>>>
>>> Question: the problem first showed up on a web service that takes a
>>> "bodyless" POST operation, and I assume it also applies to GET
>>> operations, and to the URL portion of a POST with a body.
>>>
>>> But what about the body of a POST?
>>
>>  From an HTTP specification point of view, anything goes.
> 
> With respect, I believe that "anything goes" is a bit imprecise here.

Nope.

You can POST anything. You are talking specifically about form data. In
that case, as I said, the body has to conform to what the component
processing it expects.

And yes, unicode in form data is 'interesting'...

Mark


> See e.g. https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4
> 
> There are 2 ways for a user agent to send the content of a HTTP POST :
> 1) with Content-type header = application/x-www-form-urlencoded
> or
> 2) with Content-type header = multipart/form-data
> 
> and while it is true that in the case (2), any submitted key=value pair
> would be sent separately 'as is', this would not necessarily be so in
> case (1), because then all key=value pairs would be concatenated into
> one long string, in which the different key=value pairs would be
> separated by (unescaped) "&" signs.
> (Apart from other required encodings, see the page above)
> So if the client is not a browser, and "composes" itself the POST body
> before sending it, and sends it with a Content-type (1), it had better
> encode the individual parameter pairs as described, before concatenating
> them, because that is what the server would expect.
> 
> As an additional note, if it so happened that the data in the client
> could contain Unicode text, do not forget that this is (still) not the
> standard in HTTP (and URI's, and thus query-string-like things), and
> make sure that you use the proper method to encode any printable
> characters which are not purely US-ASCII.  Again, browsers generally do
> this correctly, but custom clients not necessarily. (And a "custom
> client" in this case, could even be a bit of javascript which is
> embedded in one of your own pages, but does its own calls to the server
> on the side).
> 
> I just recently got bitten by this, even in a quite recent browser,
> where some javascript function was composing a POST to a server (using
> type (1) above), and was NOT doing it correctly, even though the page
> containing and calling this function was itself declared as Unicode/UTF-8.
> (that was with (and I am too sorely tempted to add "of course" to resist
> it) some revision of IE-11 - although other revisions of the same
> browser did not exhibit that same issue).
> 
> [...]
> 
> 
> -
> 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



Re: URL-encoding and "#"

2017-10-13 Thread tomcat

On 13.10.2017 18:17, Mark Thomas wrote:

On 13/10/2017 17:09, James H. H. Lampert wrote:

Thanks to all of you who responded.

I found a web page that explains it in ways that I can wrap my
55-year-old brain around, and has an easy-to-read reference chart.

https://perishablepress.com/stop-using-unsafe-characters-in-urls/

Question: the problem first showed up on a web service that takes a
"bodyless" POST operation, and I assume it also applies to GET
operations, and to the URL portion of a POST with a body.

But what about the body of a POST?


 From an HTTP specification point of view, anything goes.


With respect, I believe that "anything goes" is a bit imprecise here.

See e.g. https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4

There are 2 ways for a user agent to send the content of a HTTP POST :
1) with Content-type header = application/x-www-form-urlencoded
or
2) with Content-type header = multipart/form-data

and while it is true that in the case (2), any submitted key=value pair would be sent 
separately 'as is', this would not necessarily be so in case (1), because then all 
key=value pairs would be concatenated into one long string, in which the different 
key=value pairs would be separated by (unescaped) "&" signs.

(Apart from other required encodings, see the page above)
So if the client is not a browser, and "composes" itself the POST body before sending it, 
and sends it with a Content-type (1), it had better encode the individual parameter pairs 
as described, before concatenating them, because that is what the server would expect.


As an additional note, if it so happened that the data in the client could contain Unicode 
text, do not forget that this is (still) not the standard in HTTP (and URI's, and thus 
query-string-like things), and make sure that you use the proper method to encode any 
printable characters which are not purely US-ASCII.  Again, browsers generally do this 
correctly, but custom clients not necessarily. (And a "custom client" in this case, could 
even be a bit of javascript which is embedded in one of your own pages, but does its own 
calls to the server on the side).


I just recently got bitten by this, even in a quite recent browser, where some javascript 
function was composing a POST to a server (using type (1) above), and was NOT doing it 
correctly, even though the page containing and calling this function was itself declared 
as Unicode/UTF-8.
(that was with (and I am too sorely tempted to add "of course" to resist it) some revision 
of IE-11 - although other revisions of the same browser did not exhibit that same issue).


[...]


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



Re: URL-encoding and "#"

2017-10-13 Thread Mark Thomas
On 13/10/2017 17:09, James H. H. Lampert wrote:
> Thanks to all of you who responded.
> 
> I found a web page that explains it in ways that I can wrap my
> 55-year-old brain around, and has an easy-to-read reference chart.
> 
> https://perishablepress.com/stop-using-unsafe-characters-in-urls/
> 
> Question: the problem first showed up on a web service that takes a
> "bodyless" POST operation, and I assume it also applies to GET
> operations, and to the URL portion of a POST with a body.
> 
> But what about the body of a POST?

>From an HTTP specification point of view, anything goes. You are only
limited by whatever rules are imposed by the component that processes
that data.

Mark


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



Re: URL-encoding and "#"

2017-10-13 Thread James H. H. Lampert

Thanks to all of you who responded.

I found a web page that explains it in ways that I can wrap my 
55-year-old brain around, and has an easy-to-read reference chart.


https://perishablepress.com/stop-using-unsafe-characters-in-urls/

Question: the problem first showed up on a web service that takes a 
"bodyless" POST operation, and I assume it also applies to GET 
operations, and to the URL portion of a POST with a body.


But what about the body of a POST?

--
JHHL

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



Re: URL-encoding and "#"

2017-10-13 Thread i...@flyingfischer.ch
Am 13.10.2017 um 12:48 schrieb Alex O'Ree:
> Well that explains a lot. Similar issue for me. With url encoding,  tomcat
> is dropping back slash and the plus symbol.

While I think it is perfectly eligible to strive for a most perfect
alignement with standards and specs, I think Tomcat should allow a
reasonnable set of characters to be optionally allowed (as they already
are in Tomcat up to 8.5).

I am aware that these options may be a security issue and that the
documentation should state that clearly. However it is not always
possible to correct the environment to be "standard" compatible and the
educational approach by not allowing these options is understandable but
may be not appropriate in many situations.

Best regards
Markus

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



Re: URL-encoding and "#"

2017-10-13 Thread Alex O'Ree
Well that explains a lot. Similar issue for me. With url encoding,  tomcat
is dropping back slash and the plus symbol.

On Oct 13, 2017 3:01 AM, "Mark Thomas" <ma...@apache.org> wrote:

> 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=150183715500537=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
>
>


Re: URL-encoding and "#"

2017-10-13 Thread i...@flyingfischer.ch
Am 13.10.2017 um 09:01 schrieb Mark Thomas:
> 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
By the way:

While fully agreeing, that the '#' character should not be sent by a
client to the server, it still would be desirable to have those three by
optional configuration allowed characters, also be made a configurable
exception in Tomcat 9.

As fas as I know, this option has been allowed up to and including
Tomcat 8.5 only.

While it is a good thing to save the world, real world scenarios may differ.

Thanks for considering.

Markus

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



Re: URL-encoding and "#"

2017-10-13 Thread Mark Thomas
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=150183715500537=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



Re: URL-encoding and "#"

2017-10-13 Thread Peter Kreuser
Chris,




Peter Kreuser
> Am 13.10.2017 um 04:29 schrieb Christopher Schultz 
> <w...@christopherschultz.net>:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> 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.

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=150183715500537=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
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlngJRsACgkQHPApP6U8
> pFhqMg//cP4U9z0v8AzkdGRfWJilIAVdsgbA8fdfqTM0f542GzHo4tWidx6F89zK
> y2oVxz9Fr4RQev2Dgr5DyPrJnv2JYufe2S3AxBltA1jQQCu6GnqEjgzxlvmrGY05
> hhrBYBBOgBudgLXcK4bHuoIk+W5ke1Hc1n94WqyVDq2EJZUibKLJLGo3nsAItBcS
> a7jFitbzAQT/0fX/Nzo/LFanNNLenOkoKxZA0KyqzDYiwOGcsLLukOIV1AOiWgEU
> cy4dFhYkixoi8lfs5SjivNknp5tDJSq6Rf3UYChkXUcwQUTVA45AecRWvaEihwjr
> fFN91h9AVKXoVBVNjPYLKS7K7ODahR6oLNqta/2aji4QgCBnyfrPvopIG7e6fbM8
> BYo+MfpbrVi8b7ZL69d2Cl8+/6MmcUbWfuPzZsBm9Mg7tdza13NQ0vin3uyv0y6N
> 73ytO57G1CVfFK3T8v6giEMt6URpBzviF1PK0gTpBImZO13eXYVO5D8E0cXp0Q2d
> cTSC120wgwIhN4tBlrf2asjdut+0K7cpYpuAQVHFCacedhdTxDPR+OoWo4zRoYuI
> 3D776j6OoyxGCmU2GNR9kNK8q3fuVouplCapdRKPPqlbskCzmfb70SjevVGX3sAT
> /OwMwonndlCQoFOob4zg03a2rnKMritVcflffeYmih0Xm+UU7QY=
> =SwD9
> -END PGP SIGNATURE-
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
> 


Re: URL-encoding and "#"

2017-10-12 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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".

> 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
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlngJRsACgkQHPApP6U8
pFhqMg//cP4U9z0v8AzkdGRfWJilIAVdsgbA8fdfqTM0f542GzHo4tWidx6F89zK
y2oVxz9Fr4RQev2Dgr5DyPrJnv2JYufe2S3AxBltA1jQQCu6GnqEjgzxlvmrGY05
hhrBYBBOgBudgLXcK4bHuoIk+W5ke1Hc1n94WqyVDq2EJZUibKLJLGo3nsAItBcS
a7jFitbzAQT/0fX/Nzo/LFanNNLenOkoKxZA0KyqzDYiwOGcsLLukOIV1AOiWgEU
cy4dFhYkixoi8lfs5SjivNknp5tDJSq6Rf3UYChkXUcwQUTVA45AecRWvaEihwjr
fFN91h9AVKXoVBVNjPYLKS7K7ODahR6oLNqta/2aji4QgCBnyfrPvopIG7e6fbM8
BYo+MfpbrVi8b7ZL69d2Cl8+/6MmcUbWfuPzZsBm9Mg7tdza13NQ0vin3uyv0y6N
73ytO57G1CVfFK3T8v6giEMt6URpBzviF1PK0gTpBImZO13eXYVO5D8E0cXp0Q2d
cTSC120wgwIhN4tBlrf2asjdut+0K7cpYpuAQVHFCacedhdTxDPR+OoWo4zRoYuI
3D776j6OoyxGCmU2GNR9kNK8q3fuVouplCapdRKPPqlbskCzmfb70SjevVGX3sAT
/OwMwonndlCQoFOob4zg03a2rnKMritVcflffeYmih0Xm+UU7QY=
=SwD9
-END PGP SIGNATURE-

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



URL-encoding and "#"

2017-10-12 Thread James H. H. Lampert

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").


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? And if so, are there any other common ASCII characters that used 
to be accepted as characters, but now have to be URL-encoded?


--
JHHL

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



RE: Tomcat URL encoding

2017-06-15 Thread 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 <users@tomcat.apache.org>
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

2017-06-15 Thread 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

2017-06-15 Thread 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

2017-06-15 Thread 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: Increased memory consumption due to url encoding

2016-08-31 Thread Svetlin Zarev
Thanks Chris,

I've created a pull request on github:
https://github.com/apache/tomcat85/pull/3

> and then look at the diffs manually
It's an almost complete rewrite and has very little in common with the old
encoder

Svetlin

2016-08-30 20:56 GMT+03:00 Christopher Schultz :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Svetlin,
>
> On 8/28/16 12:57 PM, Svetlin Zarev wrote:
> > Hi,
> >
> > Today I had some free time, so I implemented a more (memory and
> > performance wise) efficient URLEncoder [1]  and I'd like to
> > contribute it if there is interest for improvement in that area. My
> > encoder has close to zero allocation rate (unless there is very
> > high concurrency for the encode() operations, but still will be
> > much more memory efficient than the current encoder)  and encodes
> > 2-4 times faster than the current implementation. It is available @
> > [1]. I'm open for reviews, critiques, questions, suggestions, etc.
> >
> > [1] https://github.com/SvetlinZarev/UrlEncoder
>
> Can you post this as a pull request, patch, or similar? Nobody really
> wants to download this code, replace their own local code, and then
> look at the diffs manually. I suspect that's why nobody has looked at
> it, yet.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJXxcjVAAoJEBzwKT+lPKRYsCMQAKy/pVLDeSWvcbbHMYwOLwa5
> xhBc3R0ev51qt9rMbkBTQhOZM/beM5u9AcOevFNaQlqr6knxui0R2v7fcM7LKxzU
> w8iRxe+8w1GxA/nPVmUAXU5geL7Z7gnyIf+GBhOlxn8R4cXfkvRBCOP0shZpIXPr
> fF4buxBLGOii3ApiYELdxxM6andEXc8SHd+CoCm9fc3GPMVyR4eFDEg7nNc1Y44t
> FWRBOXNCf0nJRHUDswEqK2ZTlTvd1GFTInLAy9m30uJRzkGDa3ytgfikaBE/c/Je
> ctCtz/g9xUk715YFhm23ZAmGvzi3bWBj9PZ3yTixf646Oa8WPsWWm7vALjRNZcfG
> j8Cy0ugEo1kT9wr1anIdPtr4q22E3k4Gu8SAhEObcO65dFtdZ2kvQ+tJxTceOmjn
> vyplST7kVORuhtWf+rj+L+VgHZsRR54+5C8a9Hf1/TSaI1ztWJbFIYuJr+YgnGw5
> Z264C/rWPr4fd1BRNCwJz9iHoC24IuTJAiNNcVQHrs7xKn16sW4Sq/hM5AE7oJ/5
> RhvpLtZPQmxpqVjvxPallYT0/lMN3CJ26m7A5rf0242MMf9zIsxsnnNUznhh2zNR
> gyJsTHJZ2o4tuwEclimzxrwIbO5RxgIeoTdxTbhsE4775oSQ3VHvE07yDPLlqRAh
> My3/WOXu8myi0WeLoRzE
> =5SJi
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: Increased memory consumption due to url encoding

2016-08-30 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Svetlin,

On 8/28/16 12:57 PM, Svetlin Zarev wrote:
> Hi,
> 
> Today I had some free time, so I implemented a more (memory and
> performance wise) efficient URLEncoder [1]  and I'd like to
> contribute it if there is interest for improvement in that area. My
> encoder has close to zero allocation rate (unless there is very
> high concurrency for the encode() operations, but still will be
> much more memory efficient than the current encoder)  and encodes
> 2-4 times faster than the current implementation. It is available @
> [1]. I'm open for reviews, critiques, questions, suggestions, etc.
> 
> [1] https://github.com/SvetlinZarev/UrlEncoder

Can you post this as a pull request, patch, or similar? Nobody really
wants to download this code, replace their own local code, and then
look at the diffs manually. I suspect that's why nobody has looked at
it, yet.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJXxcjVAAoJEBzwKT+lPKRYsCMQAKy/pVLDeSWvcbbHMYwOLwa5
xhBc3R0ev51qt9rMbkBTQhOZM/beM5u9AcOevFNaQlqr6knxui0R2v7fcM7LKxzU
w8iRxe+8w1GxA/nPVmUAXU5geL7Z7gnyIf+GBhOlxn8R4cXfkvRBCOP0shZpIXPr
fF4buxBLGOii3ApiYELdxxM6andEXc8SHd+CoCm9fc3GPMVyR4eFDEg7nNc1Y44t
FWRBOXNCf0nJRHUDswEqK2ZTlTvd1GFTInLAy9m30uJRzkGDa3ytgfikaBE/c/Je
ctCtz/g9xUk715YFhm23ZAmGvzi3bWBj9PZ3yTixf646Oa8WPsWWm7vALjRNZcfG
j8Cy0ugEo1kT9wr1anIdPtr4q22E3k4Gu8SAhEObcO65dFtdZ2kvQ+tJxTceOmjn
vyplST7kVORuhtWf+rj+L+VgHZsRR54+5C8a9Hf1/TSaI1ztWJbFIYuJr+YgnGw5
Z264C/rWPr4fd1BRNCwJz9iHoC24IuTJAiNNcVQHrs7xKn16sW4Sq/hM5AE7oJ/5
RhvpLtZPQmxpqVjvxPallYT0/lMN3CJ26m7A5rf0242MMf9zIsxsnnNUznhh2zNR
gyJsTHJZ2o4tuwEclimzxrwIbO5RxgIeoTdxTbhsE4775oSQ3VHvE07yDPLlqRAh
My3/WOXu8myi0WeLoRzE
=5SJi
-END PGP SIGNATURE-

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



Re: Increased memory consumption due to url encoding

2016-08-28 Thread Svetlin Zarev
Hi,

Today I had some free time, so I implemented a more (memory and performance
wise) efficient URLEncoder [1]  and I'd like to contribute it if there is
interest for improvement in that area. My encoder has close to zero
allocation rate (unless there is very high concurrency for the encode()
operations, but still will be much more memory efficient than the current
encoder)  and encodes 2-4 times faster than the current implementation. It
is available @ [1]. I'm open for reviews, critiques, questions,
suggestions, etc.

[1] https://github.com/SvetlinZarev/UrlEncoder

Svetlin


Re: Increased memory consumption due to url encoding

2016-08-12 Thread Rainer Jung

Am 11.08.2016 um 21:16 schrieb Jose María Zaragoza:

2016-08-10 14:29 GMT+02:00 Lazar Kirchev :

Hello Christopher,

I tried with 32 MB and even 24 MB heap and the CPU usage and response time
remained the almost the same (the difference is negligible) as with 1 GB
heap. The cumulative allocated memory for the HeapByteBuffer remains about
400 MB, but of course the frequency of GCs is increased.



A newbie question:

if you tried with 32 MB ( I guess -Xmx size ) , why is not raised an OOM error ?
are those 400MB allocated outside heap ?


Allocation size is not the same as size of objects in memory. An 
allocation of 400 MB during some test means the sum of the sizes of all 
objects that were created was 400 MB. The life time of those objects 
could be very short. So it is possible that only few of them were in 
memory at the same time.


An extreme example: suppose you create 1000 objects per second (or one 
per millisecond) each of size 10 KB. That means you have an allocation 
rate of 10 MB/s or after one minute 600 MB. Assume further that each 
object only lives 5 milliseconds, because it maybe is created and used 
only inside a method that runs very short. Then at each point in time 
about 5 of those objects exist which makes up only 50 KB of memory.


For many java programs the popular slogan "most objects die young" is 
correct, which means you can have high allocation rates with relatively 
small memory. Allocation is relatively cheap in Java. As always details 
go far beyond such simplistic slogans.


Regards,

Rainer

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



Re: Increased memory consumption due to url encoding

2016-08-11 Thread Jose María Zaragoza
2016-08-10 14:29 GMT+02:00 Lazar Kirchev :
> Hello Christopher,
>
> I tried with 32 MB and even 24 MB heap and the CPU usage and response time
> remained the almost the same (the difference is negligible) as with 1 GB
> heap. The cumulative allocated memory for the HeapByteBuffer remains about
> 400 MB, but of course the frequency of GCs is increased.


A newbie question:

if you tried with 32 MB ( I guess -Xmx size ) , why is not raised an OOM error ?
are those 400MB allocated outside heap ?

Thanks

>
> Regards,
> Lazar
>
> On Tue, Aug 9, 2016 at 7:27 PM, Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Lazar,
>>
>> On 8/9/16 8:40 AM, Lazar Kirchev wrote:
>> > Hello! When handling requests which make use of request dispatcher,
>> > Tomcat 7.0.70 allocates more memory in comparison to 7.0.69. This
>> > seems to come from the encoding of the path introduced with this
>> > change http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/
>> > apache/catalina/core/ApplicationContext.java?r1=1741024=1741023
>> hrev=
>> >
>> >
>> 1741024
>> > 5 requests to a very simple servlet which only gets a request
>> > dispatcher for some path lead to allocation of about 400 MB.
>> > However, after a GC they are freed and this actually does not
>> > influence CPU or response time. Has anybody noticed this effect and
>> > what do you think about it?
>>
>> What happens if you set the heap size very low (e.g. 32MiB) and run
>> the same test? Does the memory usage grow to 400MiB, or does the
>> request performance start to degrade?
>>
>> I'm curious if you are just seeing the effect of the GC doing its job
>> correctly.
>>
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQIcBAEBCAAGBQJXqgSPAAoJEBzwKT+lPKRY6+8P/2vzkhQJkPKjYAFln5wkbPp7
>> lbIVDvcH5546ch4nTQsrMPiUT/m71wwDytn6qOMzP9dIbAXjC3tBJI+nqDthkZyQ
>> ScmIi2A93JQl0aOHrMzCuS3cFk0sNdwK3n2sk8ZcFd5/KZ5cwxkyeUqwiRVbU5bA
>> MjJsEiq+r7Vgo6V3mAxMwaKS7mwLc1hcgJMrhJA8gjfeHzxhzeG0mcrIGrg5cGvl
>> mTHLovt9x1ts4KNApdt4DUSg+Yt3Fx/Gj1aoL1x1KbPM9VIJSb52IG/03WPMxIkq
>> fSM71fbZHpjZy19uV+e50sHzM0fg96RsrlQ7m5Uvjgqkz6zxNYlsX3tC0z1E7oEr
>> wq1Qi0C3dCbRe6vqnN3znYg+DyrlZ/R+qO8+35GD3ljiiDuJLpevYFNVjNceFn1Y
>> Qno6W8/2Dp1eHTxaAAVY4hhbdZyzLgxD+lOu+THkOnoZwx8Bw8TXStHIdbwtMfSz
>> 9jGuZU4W/t9uTgW6ZnauS16v2EKUbicFY9L5FB3vrRUi1qm+pYVMUdQoZtVl2yL6
>> ZoDTEZTGzvpNUoJLGDzWjp9QkXkVGIrgM7+uYXIDcMUn7QrmLLab7oGJO1pLuAlz
>> 9BJiLpjqja5eAHp/Bz1ud5ZZhBaNECJIqhkjma/+LAC1Meullf3ct4FRmL8aGfUz
>> m0ntWlqyXwr6EbmRjbFE
>> =FTq+
>> -END PGP SIGNATURE-
>>
>> -
>> 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



Re: Increased memory consumption due to url encoding

2016-08-10 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lazar,

On 8/10/16 8:29 AM, Lazar Kirchev wrote:
> I tried with 32 MB and even 24 MB heap and the CPU usage and
> response time remained the almost the same (the difference is
> negligible) as with 1 GB heap. The cumulative allocated memory for
> the HeapByteBuffer remains about 400 MB, but of course the
> frequency of GCs is increased.

Sounds like Tomcat generates a bunch of temporary garbage with that
byte buffer change, but because the objects are so short-lived, they
have no impact on the GC performance, and thus no impact on the
response time.

Remember that GC performance depends upon the number of /live/ objects
moving between generations, not the number of total objects or memory
"used" by garbage. Actual garbage is basically ignored during a GC run.

- -chris

> On Tue, Aug 9, 2016 at 7:27 PM, Christopher Schultz < 
> ch...@christopherschultz.net> wrote:
> 
> Lazar,
> 
> On 8/9/16 8:40 AM, Lazar Kirchev wrote:
 Hello! When handling requests which make use of request
 dispatcher, Tomcat 7.0.70 allocates more memory in comparison
 to 7.0.69. This seems to come from the encoding of the path
 introduced with this change
 http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/ 
 apache/catalina/core/ApplicationContext.java?r1=1741024=1741023&
pat
>
 
hrev=
 
 
> 1741024
 5 requests to a very simple servlet which only gets a
 request dispatcher for some path lead to allocation of about
 400 MB. However, after a GC they are freed and this actually
 does not influence CPU or response time. Has anybody noticed
 this effect and what do you think about it?
> 
> What happens if you set the heap size very low (e.g. 32MiB) and
> run the same test? Does the memory usage grow to 400MiB, or does
> the request performance start to degrade?
> 
> I'm curious if you are just seeing the effect of the GC doing its
> job correctly.
> 
> -chris
>> 
>> -
>>
>> 
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>> 
>> 
> 
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJXq0gVAAoJEBzwKT+lPKRYanIP/1fZ436QaLhfN/8ea3foT5gX
0fv9wK+sacg4ZTNyxVLwJa03GfS0SDNXBz9WKLa3FBxqi7WopRNqEtnH28nmCNnp
34toy+k5+IWOATn4xyboUmp6CXHTQieTO3OGmQBEg8CMOipSluOPtkq0qfPqaqKz
s//gKq0o2y3LG+7SrbHeHzf8GJiZQnIASkXBJxZ5dncJx5tHAXKbA0ji6NFlhqat
Y3E/16griZSoqhm/mVRHVZfEdvsebMDmC7cDxxakJpcxr6MjZL8aw9Tdop01aA7c
0U5ndG6jT7vJ8V1iYKblZkM0xgPuBZQln8MHuwuRVXcPgkVHhf2AOiXKrcLWtXCh
vnc0zRRn+Qat3FXrqUIv39r51+OtCO+c860Rny/t3gUXV0VSGsBLW8nAvCe8dLPf
spc4yJPEICOVsUcOk04P4ktwXQYXR6DzcV09tpHdbIeQ23YHoYAvW4O93wp4AhJ3
/rI3t4dCCFWpxutsVxBmrVpgbLJg78kpZTauu35Q0oJBHPYGxjn+mOdqZMSXnn3X
3afrr9nmneyW/YUEj0sUclr5HtbqHojStphf7SYczMlnDpOg5DVGGnSJLK2gvJVQ
Plu1qsA0uJ1NUEFRLkQ0FwyxSZl8EtfSQHqZnh/pgulto38dRa7kSRgUylHWnpI3
9uV9gLnKuBWlqg+y16UV
=tW0i
-END PGP SIGNATURE-

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



Re: Increased memory consumption due to url encoding

2016-08-10 Thread Lazar Kirchev
Hello Christopher,

I tried with 32 MB and even 24 MB heap and the CPU usage and response time
remained the almost the same (the difference is negligible) as with 1 GB
heap. The cumulative allocated memory for the HeapByteBuffer remains about
400 MB, but of course the frequency of GCs is increased.

Regards,
Lazar

On Tue, Aug 9, 2016 at 7:27 PM, Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Lazar,
>
> On 8/9/16 8:40 AM, Lazar Kirchev wrote:
> > Hello! When handling requests which make use of request dispatcher,
> > Tomcat 7.0.70 allocates more memory in comparison to 7.0.69. This
> > seems to come from the encoding of the path introduced with this
> > change http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/
> > apache/catalina/core/ApplicationContext.java?r1=1741024=1741023
> hrev=
> >
> >
> 1741024
> > 5 requests to a very simple servlet which only gets a request
> > dispatcher for some path lead to allocation of about 400 MB.
> > However, after a GC they are freed and this actually does not
> > influence CPU or response time. Has anybody noticed this effect and
> > what do you think about it?
>
> What happens if you set the heap size very low (e.g. 32MiB) and run
> the same test? Does the memory usage grow to 400MiB, or does the
> request performance start to degrade?
>
> I'm curious if you are just seeing the effect of the GC doing its job
> correctly.
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJXqgSPAAoJEBzwKT+lPKRY6+8P/2vzkhQJkPKjYAFln5wkbPp7
> lbIVDvcH5546ch4nTQsrMPiUT/m71wwDytn6qOMzP9dIbAXjC3tBJI+nqDthkZyQ
> ScmIi2A93JQl0aOHrMzCuS3cFk0sNdwK3n2sk8ZcFd5/KZ5cwxkyeUqwiRVbU5bA
> MjJsEiq+r7Vgo6V3mAxMwaKS7mwLc1hcgJMrhJA8gjfeHzxhzeG0mcrIGrg5cGvl
> mTHLovt9x1ts4KNApdt4DUSg+Yt3Fx/Gj1aoL1x1KbPM9VIJSb52IG/03WPMxIkq
> fSM71fbZHpjZy19uV+e50sHzM0fg96RsrlQ7m5Uvjgqkz6zxNYlsX3tC0z1E7oEr
> wq1Qi0C3dCbRe6vqnN3znYg+DyrlZ/R+qO8+35GD3ljiiDuJLpevYFNVjNceFn1Y
> Qno6W8/2Dp1eHTxaAAVY4hhbdZyzLgxD+lOu+THkOnoZwx8Bw8TXStHIdbwtMfSz
> 9jGuZU4W/t9uTgW6ZnauS16v2EKUbicFY9L5FB3vrRUi1qm+pYVMUdQoZtVl2yL6
> ZoDTEZTGzvpNUoJLGDzWjp9QkXkVGIrgM7+uYXIDcMUn7QrmLLab7oGJO1pLuAlz
> 9BJiLpjqja5eAHp/Bz1ud5ZZhBaNECJIqhkjma/+LAC1Meullf3ct4FRmL8aGfUz
> m0ntWlqyXwr6EbmRjbFE
> =FTq+
> -END PGP SIGNATURE-
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>


Re: Increased memory consumption due to url encoding

2016-08-09 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lazar,

On 8/9/16 8:40 AM, Lazar Kirchev wrote:
> Hello! When handling requests which make use of request dispatcher,
> Tomcat 7.0.70 allocates more memory in comparison to 7.0.69. This
> seems to come from the encoding of the path introduced with this
> change http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/ 
> apache/catalina/core/ApplicationContext.java?r1=1741024=1741023
hrev=
>
> 
1741024
> 5 requests to a very simple servlet which only gets a request 
> dispatcher for some path lead to allocation of about 400 MB.
> However, after a GC they are freed and this actually does not
> influence CPU or response time. Has anybody noticed this effect and
> what do you think about it?

What happens if you set the heap size very low (e.g. 32MiB) and run
the same test? Does the memory usage grow to 400MiB, or does the
request performance start to degrade?

I'm curious if you are just seeing the effect of the GC doing its job
correctly.

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJXqgSPAAoJEBzwKT+lPKRY6+8P/2vzkhQJkPKjYAFln5wkbPp7
lbIVDvcH5546ch4nTQsrMPiUT/m71wwDytn6qOMzP9dIbAXjC3tBJI+nqDthkZyQ
ScmIi2A93JQl0aOHrMzCuS3cFk0sNdwK3n2sk8ZcFd5/KZ5cwxkyeUqwiRVbU5bA
MjJsEiq+r7Vgo6V3mAxMwaKS7mwLc1hcgJMrhJA8gjfeHzxhzeG0mcrIGrg5cGvl
mTHLovt9x1ts4KNApdt4DUSg+Yt3Fx/Gj1aoL1x1KbPM9VIJSb52IG/03WPMxIkq
fSM71fbZHpjZy19uV+e50sHzM0fg96RsrlQ7m5Uvjgqkz6zxNYlsX3tC0z1E7oEr
wq1Qi0C3dCbRe6vqnN3znYg+DyrlZ/R+qO8+35GD3ljiiDuJLpevYFNVjNceFn1Y
Qno6W8/2Dp1eHTxaAAVY4hhbdZyzLgxD+lOu+THkOnoZwx8Bw8TXStHIdbwtMfSz
9jGuZU4W/t9uTgW6ZnauS16v2EKUbicFY9L5FB3vrRUi1qm+pYVMUdQoZtVl2yL6
ZoDTEZTGzvpNUoJLGDzWjp9QkXkVGIrgM7+uYXIDcMUn7QrmLLab7oGJO1pLuAlz
9BJiLpjqja5eAHp/Bz1ud5ZZhBaNECJIqhkjma/+LAC1Meullf3ct4FRmL8aGfUz
m0ntWlqyXwr6EbmRjbFE
=FTq+
-END PGP SIGNATURE-

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



Increased memory consumption due to url encoding

2016-08-09 Thread Lazar Kirchev
Hello!
When handling requests which make use of request dispatcher, Tomcat 7.0.70
allocates more memory in comparison to 7.0.69. This seems to come from the
encoding of the path introduced with this change
http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/
apache/catalina/core/ApplicationContext.java?r1=1741024=1741023=
1741024
5 requests to a very simple servlet which only gets a request
dispatcher for some path lead to allocation of about 400 MB. However, after
a GC they are freed and this actually does not influence CPU or response
time.
Has anybody noticed this effect and what do you think about it?

Kind regards,
Lazar


Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

2016-07-07 Thread Mark Thomas
On 07/07/2016 19:49, Mekkelsen Madden, Steve wrote:
> This was reproduced in dev, staging, testqa on multiple servers.  Yes, the 
> response shown is JSON which is puzzling since that only appears when using 
> NIO2.  That's why there is so much confusion on this.  At the end of the day, 
> I simply deployed Tomcat 8.5.3x64 Windows to each server and migrated all the 
> settings from 8.0.32 to 8.5.3 respectively in the context.xml, server.xml, 
> tomcat-users.xml and web.xml.  The biggest change in 8.5.3 was the 
> significant differences in SSL/TLS configuration required to get Tomcat to 
> even startup properly.  I'm referring specifically to the connector arguments 
> that have changed.  As an example (noting that this works with NIO, but not 
> as shown with NIO2):
> ***We used to have:***
> protocol="org.apache.coyote.http11.Http11Nio2Protocol" maxThreads="10" 
> minSpareThreads="5" acceptCount="100" connectionTimeout="6" 
> disableUploadTimeout="true"  clientAuth="false" secure="true" scheme="https" 
> SSLEnabled="true" sslProtocol="TLS" sslEnabledProtocols="TLSv1.1,TLSv1.2" 
> keystoreFile="D:\certificates\ourJKS.keystore" keystorePass="**" />   
> 
> 
> 
> ***Now changed with 8.5.3 settings:***
>   
> protocol="org.apache.coyote.http11.Http11Nio2Protocol" 
>   maxThreads="150" disableUploadTimeout="true"  
>   SSLEnabled="true"
>   sslDefaultHost="ourServer.com">
>
>certificateKeystoreFile="D:\certificates\ourJKS.keystore" 
> certificateKeystorePassword="**" certificateKeyAlias="ourAlias" 
> type="RSA"/>
>
>   
> 
> 
> 
> Am I missing something here?  Has anyone else tried to do the same with NIO2 
> protocol and it worked? :-)

Tomcat 8.5.x should work with a 8.0.x TLS configuration as long as there
is only one TLS virtual host (Tomcat will auto-convert everything on the
fly).

I don't recall anything like this previously. If you can provide the
simplest possible test case that demonstrates it, open a Bugzilla issue,
attach the test case and someone will take a look.

There is a major connector refactoring between 8.0.x and 8.5.x but
generally I'd expect things to be better as there is less code
duplication and better consistency of behaviour for numerous edge cases
in 8.5.x compared to 8.0.x.

Mark


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



RE: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

2016-07-07 Thread Mekkelsen Madden, Steve
This was reproduced in dev, staging, testqa on multiple servers.  Yes, the 
response shown is JSON which is puzzling since that only appears when using 
NIO2.  That's why there is so much confusion on this.  At the end of the day, I 
simply deployed Tomcat 8.5.3x64 Windows to each server and migrated all the 
settings from 8.0.32 to 8.5.3 respectively in the context.xml, server.xml, 
tomcat-users.xml and web.xml.  The biggest change in 8.5.3 was the significant 
differences in SSL/TLS configuration required to get Tomcat to even startup 
properly.  I'm referring specifically to the connector arguments that have 
changed.  As an example (noting that this works with NIO, but not as shown with 
NIO2):
***We used to have:***




***Now changed with 8.5.3 settings:***
 
 

 




Am I missing something here?  Has anyone else tried to do the same with NIO2 
protocol and it worked? :-)

Regards,

Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
Master  | GCS |  Pegasystems Inc.
Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
steve.mekkelsen.mad...@pega.com | www.pega.com


-Original Message-
From: Felix Schumacher [mailto:felix.schumac...@internetallee.de] 
Sent: Thursday, July 07, 2016 12:53 PM
To: users@tomcat.apache.org
Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

Am 07.07.2016 um 18:32 schrieb Mekkelsen Madden, Steve:
> Every request, making the environment virtually unstable and unusable since 
> everything we do is using xml.
The second logs showed json :) In any case, can you reproduce the issue in a 
dev environment? It would be superb, if you could make a minimal case, where 
this happens.

Regards,
  Felix
>
> Regards,
>
> Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
> Master  | GCS |  Pegasystems Inc.
> Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
> steve.mekkelsen.mad...@pega.com | www.pega.com
>
>
> -Original Message-
> From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
> Sent: Thursday, July 07, 2016 12:30 PM
> To: users@tomcat.apache.org
> Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding 
> issues
>
> Am 07.07.2016 um 15:04 schrieb Mekkelsen Madden, Steve:
>> Hi, sorry for delay and misinformation of the screenshot.  The 
>> screenshot shows Fiddler seeing the correct xml using both NIO and 
>> NIO2 protocols.  Fiddler does not see anything wrong with the 
>> requests themselves.  However, when we enable more debugging on our 
>> server, the logs are showing this: http://pastebin.com/ShYzr92e
>>
>> Note that, this is the same test case run with NIO (which works fine and no 
>> errors) but fails in NIO2.  Also, that we have been using NIO2 for many 
>> months without any issues under Tomcat 8.0.32.  It wasn't until the upgrade 
>> to 8.5.3 that NIO2 just stopped working.  Hope this helps.
> Can you print out the data on the server side when it fails to parse?
>
> Is this happening on every request or randomly?
>
> Regards,
>Felix
>> Regards,
>>
>> Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
>> Master  | GCS |  Pegasystems Inc.
>> Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
>> steve.mekkelsen.mad...@pega.com | www.pega.com
>>
>>
>> -Original Message-
>> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
>> Sent: Wednesday, July 06, 2016 4:45 PM
>> To: Tomcat Users List <users@tomcat.apache.org>
>> Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url 
>> encoding issues
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Steve,
>>
>> On 7/6/16 4:22 PM, Mekkelsen Madden, Steve wrote:
>>> Here is the image I tried attaching.  Sorry about that.
>>> [redacted... my SMTP server really doesn't like that URL]
>> So... what are we looking at, here?
>>
>> I see a POST URL that looks perfectly fine. I also see XML in the POST 
>> request. Is this a shot of Fiddler? Where is the problem?
>>
>> - -chris
>> -BEGIN PGP SIGNATURE-
>> Comment: GPGTools - http://gpgtools.org
>> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>>
>> iQIcBAEBCAAGBQJXfW3LAAoJEBzwKT+lPKRYGsMP/3h+wQNIHoC/95G0VxQY75Kh
>> ClI+ny5Z5NeyVsA8iCrZ1rIr/fBEzE/nnHWlX16yPhkaCBQ8PwJ+i2MV11rYArU9
>> yUIhL2xyAxVAqyBUZGrNidzz6gydvJd2MPNGrtHg6shaIA7XtflX9gMUV16J+3m+
>> 7VC+E+lLBwOEcrYbpxJNni36Cn4QQ6f6sHMgLKsbGZZ6PSl7MGVPts6oz6SUkt6T
>> rwwPF6QLuovnndWlqt9HDaJtTD9/a9emSZgXKPQYACp8poSZ8xM7SxPn9f1XnX6l
>> iyOEc9RYJ3bvKocC8iMKCpS

Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

2016-07-07 Thread hugh holston
users-unsubscr...@tomcat.apache.org please unsubsribe

  From: "Mekkelsen Madden, Steve" <steve.mekkelsenmad...@pega.com>
 To: Tomcat Users List <users@tomcat.apache.org> 
 Sent: Thursday, July 7, 2016 11:32 AM
 Subject: RE: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues
   
Every request, making the environment virtually unstable and unusable since 
everything we do is using xml.

Regards,

Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
Master  | GCS |  Pegasystems Inc.
Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
steve.mekkelsen.mad...@pega.com | www.pega.com


-Original Message-
From: Felix Schumacher [mailto:felix.schumac...@internetallee.de] 
Sent: Thursday, July 07, 2016 12:30 PM
To: users@tomcat.apache.org
Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

Am 07.07.2016 um 15:04 schrieb Mekkelsen Madden, Steve:
> Hi, sorry for delay and misinformation of the screenshot.  The screenshot 
> shows Fiddler seeing the correct xml using both NIO and NIO2 protocols.  
> Fiddler does not see anything wrong with the requests themselves.  However, 
> when we enable more debugging on our server, the logs are showing this: 
> http://pastebin.com/ShYzr92e
>
> Note that, this is the same test case run with NIO (which works fine and no 
> errors) but fails in NIO2.  Also, that we have been using NIO2 for many 
> months without any issues under Tomcat 8.0.32.  It wasn't until the upgrade 
> to 8.5.3 that NIO2 just stopped working.  Hope this helps.
Can you print out the data on the server side when it fails to parse?

Is this happening on every request or randomly?

Regards,
  Felix
>
> Regards,
>
> Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
> Master  | GCS |  Pegasystems Inc.
> Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
> steve.mekkelsen.mad...@pega.com | www.pega.com
>
>
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, July 06, 2016 4:45 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Steve,
>
> On 7/6/16 4:22 PM, Mekkelsen Madden, Steve wrote:
>> Here is the image I tried attaching.  Sorry about that.
>> [redacted... my SMTP server really doesn't like that URL]
> So... what are we looking at, here?
>
> I see a POST URL that looks perfectly fine. I also see XML in the POST 
> request. Is this a shot of Fiddler? Where is the problem?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJXfW3LAAoJEBzwKT+lPKRYGsMP/3h+wQNIHoC/95G0VxQY75Kh
> ClI+ny5Z5NeyVsA8iCrZ1rIr/fBEzE/nnHWlX16yPhkaCBQ8PwJ+i2MV11rYArU9
> yUIhL2xyAxVAqyBUZGrNidzz6gydvJd2MPNGrtHg6shaIA7XtflX9gMUV16J+3m+
> 7VC+E+lLBwOEcrYbpxJNni36Cn4QQ6f6sHMgLKsbGZZ6PSl7MGVPts6oz6SUkt6T
> rwwPF6QLuovnndWlqt9HDaJtTD9/a9emSZgXKPQYACp8poSZ8xM7SxPn9f1XnX6l
> iyOEc9RYJ3bvKocC8iMKCpSn41/XAGpiS3dwpYbNrN15sd2emRze2seDfJVI4Xtm
> 1d7GRqXUadjCjq/PzDSihrFjHBU+6+7BKd/hdqn6raci6HbtQPizkUTkPDWPXUTg
> T9Y7TOvi9zZNro9jLxErluN/A/niY8so53DFqT2kxV9wr2COf3dRu8UTyFM/4Mul
> 6bcGpno5CjvpfwVltlB8BTwRUctGEWe3kYcUfUBOTMNFFAMUYq+/4saL/gOATD8P
> LMcNXqbkex5fPrARU+vGgQvanFGeZMR7w9UXJbd9ACEWJUgRAnr18/5RtbVzWVjO
> gd4uPaLFgyFV573Hpe4Luzg7OngDu7BXZqThKXXaiG4cZSKmdjyjJVb4709GMOWc
> ARZb7MipIot/KGBBJhNd
> =bPg7
> -END PGP SIGNATURE-
>
> -
> 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
>


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

B‹CB•È[œÝXœØÜšX™KK[XZ[ˆ\Ù\œË][œÝXœØÜšX™PÛXØ]˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ËK[XZ[ˆ\Ù\œËZ[ÛXØ]˜\XÚK›Ü™ÃBƒ

  

Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

2016-07-07 Thread Felix Schumacher

Am 07.07.2016 um 18:32 schrieb Mekkelsen Madden, Steve:

Every request, making the environment virtually unstable and unusable since 
everything we do is using xml.
The second logs showed json :) In any case, can you reproduce the issue 
in a dev environment? It would be superb, if you could make a minimal 
case, where this happens.


Regards,
 Felix


Regards,

Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
Master  | GCS |  Pegasystems Inc.
Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
steve.mekkelsen.mad...@pega.com | www.pega.com


-Original Message-
From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
Sent: Thursday, July 07, 2016 12:30 PM
To: users@tomcat.apache.org
Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

Am 07.07.2016 um 15:04 schrieb Mekkelsen Madden, Steve:

Hi, sorry for delay and misinformation of the screenshot.  The screenshot shows 
Fiddler seeing the correct xml using both NIO and NIO2 protocols.  Fiddler does 
not see anything wrong with the requests themselves.  However, when we enable 
more debugging on our server, the logs are showing this: 
http://pastebin.com/ShYzr92e

Note that, this is the same test case run with NIO (which works fine and no 
errors) but fails in NIO2.  Also, that we have been using NIO2 for many months 
without any issues under Tomcat 8.0.32.  It wasn't until the upgrade to 8.5.3 
that NIO2 just stopped working.  Hope this helps.

Can you print out the data on the server side when it fails to parse?

Is this happening on every request or randomly?

Regards,
   Felix

Regards,

Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
Master  | GCS |  Pegasystems Inc.
Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
steve.mekkelsen.mad...@pega.com | www.pega.com


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Wednesday, July 06, 2016 4:45 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Steve,

On 7/6/16 4:22 PM, Mekkelsen Madden, Steve wrote:

Here is the image I tried attaching.  Sorry about that.
[redacted... my SMTP server really doesn't like that URL]

So... what are we looking at, here?

I see a POST URL that looks perfectly fine. I also see XML in the POST request. 
Is this a shot of Fiddler? Where is the problem?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJXfW3LAAoJEBzwKT+lPKRYGsMP/3h+wQNIHoC/95G0VxQY75Kh
ClI+ny5Z5NeyVsA8iCrZ1rIr/fBEzE/nnHWlX16yPhkaCBQ8PwJ+i2MV11rYArU9
yUIhL2xyAxVAqyBUZGrNidzz6gydvJd2MPNGrtHg6shaIA7XtflX9gMUV16J+3m+
7VC+E+lLBwOEcrYbpxJNni36Cn4QQ6f6sHMgLKsbGZZ6PSl7MGVPts6oz6SUkt6T
rwwPF6QLuovnndWlqt9HDaJtTD9/a9emSZgXKPQYACp8poSZ8xM7SxPn9f1XnX6l
iyOEc9RYJ3bvKocC8iMKCpSn41/XAGpiS3dwpYbNrN15sd2emRze2seDfJVI4Xtm
1d7GRqXUadjCjq/PzDSihrFjHBU+6+7BKd/hdqn6raci6HbtQPizkUTkPDWPXUTg
T9Y7TOvi9zZNro9jLxErluN/A/niY8so53DFqT2kxV9wr2COf3dRu8UTyFM/4Mul
6bcGpno5CjvpfwVltlB8BTwRUctGEWe3kYcUfUBOTMNFFAMUYq+/4saL/gOATD8P
LMcNXqbkex5fPrARU+vGgQvanFGeZMR7w9UXJbd9ACEWJUgRAnr18/5RtbVzWVjO
gd4uPaLFgyFV573Hpe4Luzg7OngDu7BXZqThKXXaiG4cZSKmdjyjJVb4709GMOWc
ARZb7MipIot/KGBBJhNd
=bPg7
-END PGP SIGNATURE-

-
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



-
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




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



RE: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

2016-07-07 Thread Mekkelsen Madden, Steve
Every request, making the environment virtually unstable and unusable since 
everything we do is using xml.

Regards,

Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
Master  | GCS |  Pegasystems Inc.
Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
steve.mekkelsen.mad...@pega.com | www.pega.com


-Original Message-
From: Felix Schumacher [mailto:felix.schumac...@internetallee.de] 
Sent: Thursday, July 07, 2016 12:30 PM
To: users@tomcat.apache.org
Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

Am 07.07.2016 um 15:04 schrieb Mekkelsen Madden, Steve:
> Hi, sorry for delay and misinformation of the screenshot.  The screenshot 
> shows Fiddler seeing the correct xml using both NIO and NIO2 protocols.  
> Fiddler does not see anything wrong with the requests themselves.  However, 
> when we enable more debugging on our server, the logs are showing this: 
> http://pastebin.com/ShYzr92e
>
> Note that, this is the same test case run with NIO (which works fine and no 
> errors) but fails in NIO2.  Also, that we have been using NIO2 for many 
> months without any issues under Tomcat 8.0.32.  It wasn't until the upgrade 
> to 8.5.3 that NIO2 just stopped working.  Hope this helps.
Can you print out the data on the server side when it fails to parse?

Is this happening on every request or randomly?

Regards,
  Felix
>
> Regards,
>
> Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
> Master  | GCS |  Pegasystems Inc.
> Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
> steve.mekkelsen.mad...@pega.com | www.pega.com
>
>
> -Original Message-
> From: Christopher Schultz [mailto:ch...@christopherschultz.net]
> Sent: Wednesday, July 06, 2016 4:45 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Steve,
>
> On 7/6/16 4:22 PM, Mekkelsen Madden, Steve wrote:
>> Here is the image I tried attaching.  Sorry about that.
>> [redacted... my SMTP server really doesn't like that URL]
> So... what are we looking at, here?
>
> I see a POST URL that looks perfectly fine. I also see XML in the POST 
> request. Is this a shot of Fiddler? Where is the problem?
>
> - -chris
> -BEGIN PGP SIGNATURE-
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJXfW3LAAoJEBzwKT+lPKRYGsMP/3h+wQNIHoC/95G0VxQY75Kh
> ClI+ny5Z5NeyVsA8iCrZ1rIr/fBEzE/nnHWlX16yPhkaCBQ8PwJ+i2MV11rYArU9
> yUIhL2xyAxVAqyBUZGrNidzz6gydvJd2MPNGrtHg6shaIA7XtflX9gMUV16J+3m+
> 7VC+E+lLBwOEcrYbpxJNni36Cn4QQ6f6sHMgLKsbGZZ6PSl7MGVPts6oz6SUkt6T
> rwwPF6QLuovnndWlqt9HDaJtTD9/a9emSZgXKPQYACp8poSZ8xM7SxPn9f1XnX6l
> iyOEc9RYJ3bvKocC8iMKCpSn41/XAGpiS3dwpYbNrN15sd2emRze2seDfJVI4Xtm
> 1d7GRqXUadjCjq/PzDSihrFjHBU+6+7BKd/hdqn6raci6HbtQPizkUTkPDWPXUTg
> T9Y7TOvi9zZNro9jLxErluN/A/niY8so53DFqT2kxV9wr2COf3dRu8UTyFM/4Mul
> 6bcGpno5CjvpfwVltlB8BTwRUctGEWe3kYcUfUBOTMNFFAMUYq+/4saL/gOATD8P
> LMcNXqbkex5fPrARU+vGgQvanFGeZMR7w9UXJbd9ACEWJUgRAnr18/5RtbVzWVjO
> gd4uPaLFgyFV573Hpe4Luzg7OngDu7BXZqThKXXaiG4cZSKmdjyjJVb4709GMOWc
> ARZb7MipIot/KGBBJhNd
> =bPg7
> -END PGP SIGNATURE-
>
> -
> 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
>


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



Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

2016-07-07 Thread Felix Schumacher

Am 07.07.2016 um 15:04 schrieb Mekkelsen Madden, Steve:

Hi, sorry for delay and misinformation of the screenshot.  The screenshot shows 
Fiddler seeing the correct xml using both NIO and NIO2 protocols.  Fiddler does 
not see anything wrong with the requests themselves.  However, when we enable 
more debugging on our server, the logs are showing this: 
http://pastebin.com/ShYzr92e

Note that, this is the same test case run with NIO (which works fine and no 
errors) but fails in NIO2.  Also, that we have been using NIO2 for many months 
without any issues under Tomcat 8.0.32.  It wasn't until the upgrade to 8.5.3 
that NIO2 just stopped working.  Hope this helps.

Can you print out the data on the server side when it fails to parse?

Is this happening on every request or randomly?

Regards,
 Felix


Regards,

Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
Master  | GCS |  Pegasystems Inc.
Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
steve.mekkelsen.mad...@pega.com | www.pega.com


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net]
Sent: Wednesday, July 06, 2016 4:45 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Steve,

On 7/6/16 4:22 PM, Mekkelsen Madden, Steve wrote:

Here is the image I tried attaching.  Sorry about that.
[redacted... my SMTP server really doesn't like that URL]

So... what are we looking at, here?

I see a POST URL that looks perfectly fine. I also see XML in the POST request. 
Is this a shot of Fiddler? Where is the problem?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJXfW3LAAoJEBzwKT+lPKRYGsMP/3h+wQNIHoC/95G0VxQY75Kh
ClI+ny5Z5NeyVsA8iCrZ1rIr/fBEzE/nnHWlX16yPhkaCBQ8PwJ+i2MV11rYArU9
yUIhL2xyAxVAqyBUZGrNidzz6gydvJd2MPNGrtHg6shaIA7XtflX9gMUV16J+3m+
7VC+E+lLBwOEcrYbpxJNni36Cn4QQ6f6sHMgLKsbGZZ6PSl7MGVPts6oz6SUkt6T
rwwPF6QLuovnndWlqt9HDaJtTD9/a9emSZgXKPQYACp8poSZ8xM7SxPn9f1XnX6l
iyOEc9RYJ3bvKocC8iMKCpSn41/XAGpiS3dwpYbNrN15sd2emRze2seDfJVI4Xtm
1d7GRqXUadjCjq/PzDSihrFjHBU+6+7BKd/hdqn6raci6HbtQPizkUTkPDWPXUTg
T9Y7TOvi9zZNro9jLxErluN/A/niY8so53DFqT2kxV9wr2COf3dRu8UTyFM/4Mul
6bcGpno5CjvpfwVltlB8BTwRUctGEWe3kYcUfUBOTMNFFAMUYq+/4saL/gOATD8P
LMcNXqbkex5fPrARU+vGgQvanFGeZMR7w9UXJbd9ACEWJUgRAnr18/5RtbVzWVjO
gd4uPaLFgyFV573Hpe4Luzg7OngDu7BXZqThKXXaiG4cZSKmdjyjJVb4709GMOWc
ARZb7MipIot/KGBBJhNd
=bPg7
-END PGP SIGNATURE-

-
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




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



RE: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

2016-07-07 Thread Mekkelsen Madden, Steve
Hi, sorry for delay and misinformation of the screenshot.  The screenshot shows 
Fiddler seeing the correct xml using both NIO and NIO2 protocols.  Fiddler does 
not see anything wrong with the requests themselves.  However, when we enable 
more debugging on our server, the logs are showing this: 
http://pastebin.com/ShYzr92e

Note that, this is the same test case run with NIO (which works fine and no 
errors) but fails in NIO2.  Also, that we have been using NIO2 for many months 
without any issues under Tomcat 8.0.32.  It wasn't until the upgrade to 8.5.3 
that NIO2 just stopped working.  Hope this helps.

Regards,

Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
Master  | GCS |  Pegasystems Inc.
Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
steve.mekkelsen.mad...@pega.com | www.pega.com


-Original Message-
From: Christopher Schultz [mailto:ch...@christopherschultz.net] 
Sent: Wednesday, July 06, 2016 4:45 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Steve,

On 7/6/16 4:22 PM, Mekkelsen Madden, Steve wrote:
> Here is the image I tried attaching.  Sorry about that. 
> [redacted... my SMTP server really doesn't like that URL]

So... what are we looking at, here?

I see a POST URL that looks perfectly fine. I also see XML in the POST request. 
Is this a shot of Fiddler? Where is the problem?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJXfW3LAAoJEBzwKT+lPKRYGsMP/3h+wQNIHoC/95G0VxQY75Kh
ClI+ny5Z5NeyVsA8iCrZ1rIr/fBEzE/nnHWlX16yPhkaCBQ8PwJ+i2MV11rYArU9
yUIhL2xyAxVAqyBUZGrNidzz6gydvJd2MPNGrtHg6shaIA7XtflX9gMUV16J+3m+
7VC+E+lLBwOEcrYbpxJNni36Cn4QQ6f6sHMgLKsbGZZ6PSl7MGVPts6oz6SUkt6T
rwwPF6QLuovnndWlqt9HDaJtTD9/a9emSZgXKPQYACp8poSZ8xM7SxPn9f1XnX6l
iyOEc9RYJ3bvKocC8iMKCpSn41/XAGpiS3dwpYbNrN15sd2emRze2seDfJVI4Xtm
1d7GRqXUadjCjq/PzDSihrFjHBU+6+7BKd/hdqn6raci6HbtQPizkUTkPDWPXUTg
T9Y7TOvi9zZNro9jLxErluN/A/niY8so53DFqT2kxV9wr2COf3dRu8UTyFM/4Mul
6bcGpno5CjvpfwVltlB8BTwRUctGEWe3kYcUfUBOTMNFFAMUYq+/4saL/gOATD8P
LMcNXqbkex5fPrARU+vGgQvanFGeZMR7w9UXJbd9ACEWJUgRAnr18/5RtbVzWVjO
gd4uPaLFgyFV573Hpe4Luzg7OngDu7BXZqThKXXaiG4cZSKmdjyjJVb4709GMOWc
ARZb7MipIot/KGBBJhNd
=bPg7
-END PGP SIGNATURE-

-
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



Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

2016-07-06 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Steve,

On 7/6/16 4:22 PM, Mekkelsen Madden, Steve wrote:
> Here is the image I tried attaching.  Sorry about that. 
> [redacted... my SMTP server really doesn't like that URL]

So... what are we looking at, here?

I see a POST URL that looks perfectly fine. I also see XML in the POST
request. Is this a shot of Fiddler? Where is the problem?

- -chris
-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJXfW3LAAoJEBzwKT+lPKRYGsMP/3h+wQNIHoC/95G0VxQY75Kh
ClI+ny5Z5NeyVsA8iCrZ1rIr/fBEzE/nnHWlX16yPhkaCBQ8PwJ+i2MV11rYArU9
yUIhL2xyAxVAqyBUZGrNidzz6gydvJd2MPNGrtHg6shaIA7XtflX9gMUV16J+3m+
7VC+E+lLBwOEcrYbpxJNni36Cn4QQ6f6sHMgLKsbGZZ6PSl7MGVPts6oz6SUkt6T
rwwPF6QLuovnndWlqt9HDaJtTD9/a9emSZgXKPQYACp8poSZ8xM7SxPn9f1XnX6l
iyOEc9RYJ3bvKocC8iMKCpSn41/XAGpiS3dwpYbNrN15sd2emRze2seDfJVI4Xtm
1d7GRqXUadjCjq/PzDSihrFjHBU+6+7BKd/hdqn6raci6HbtQPizkUTkPDWPXUTg
T9Y7TOvi9zZNro9jLxErluN/A/niY8so53DFqT2kxV9wr2COf3dRu8UTyFM/4Mul
6bcGpno5CjvpfwVltlB8BTwRUctGEWe3kYcUfUBOTMNFFAMUYq+/4saL/gOATD8P
LMcNXqbkex5fPrARU+vGgQvanFGeZMR7w9UXJbd9ACEWJUgRAnr18/5RtbVzWVjO
gd4uPaLFgyFV573Hpe4Luzg7OngDu7BXZqThKXXaiG4cZSKmdjyjJVb4709GMOWc
ARZb7MipIot/KGBBJhNd
=bPg7
-END PGP SIGNATURE-

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



RE: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

2016-07-06 Thread Mekkelsen Madden, Steve
Here is the image I tried attaching.  Sorry about that.  
https://ibin.co/2n9zIx3n9qUH.jpg


Regards,

Steve Mekkelsen Madden  |  Systems Engineer Fellow / DBA / Certified Scrum 
Master  | GCS |  Pegasystems Inc.
Office: (617) 866.6023 | Mobile: (828) 729.9948 | Email: 
steve.mekkelsen.mad...@pega.com | www.pega.com


-Original Message-
From: Mekkelsen Madden, Steve 
Sent: Wednesday, July 06, 2016 3:44 PM
To: users@tomcat.apache.org
Subject: RE: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

Thanks Felix. See below


-Original Message-
From: Felix Schumacher [mailto:felix.schumac...@internetallee.de]
Sent: Wednesday, July 06, 2016 3:29 PM
To: users@tomcat.apache.org
Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

Am 06.07.2016 um 19:14 schrieb Mekkelsen Madden, Steve:
> This particular issue has raised a lot of issues in-house and we would 
> greatly appreciate a response from someone having more details on why NIO2 no 
> longer works.
>
> Thanks!
>
>
> -Original Message-
> From: Mekkelsen Madden, Steve
> Sent: Friday, July 01, 2016 12:56 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding 
> issues
>
> Hi all,
>
> Is anyone aware of why after upgrading from Tomcat 8.0.32x64 (Windows) to 
> 8.5.3x64 using the connector protocol of: 
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"  fails with url 
> encoding errors?  Once it was changed back to 
> protocol="org.apache.coyote.http11.Http11NioProtocol" all the errors stopped. 
>  This completely broke the application and made it unusable as the xml being 
> returned was not decoded and resulted in sax parse exceptions with our AJAX 
> connections.   I haven't found anything related to the protocol changing, 
> only the parameters for the SSL/TLS attributes which are in place and work.  
> It's almost like it's blocking the requests when it should be unblocking the 
> requests?  Thanks!!
Have you tried to compare the responses, that you get through the two 
connectors? Especially the characters before the xml prolog would be 
interesting.
Do you get the same errors, when you are requesting the url without tls?

Regards,
  Felix

Steve: We did not try turning off TLS in this case since this is what was 
already enabled in Production and required due to servers being accessible 
outside the network.  What the engineer found is that Fiddler showed all XML 
content (all the strings) that is being sent to and from the server were being 
encoded.  However, the XML content in fiddler does not have the encoded 
content.  I've attached a screenshot showing the request if that helps.

>
> Database Type: Oracle 12c Linux x64
> Driver used: ojdbc7.jar
> Connector attribute:  
>protocol="org.apache.coyote.http11.Http11NioProtocol"
>   maxThreads="150" disableUploadTimeout="true"
>   SSLEnabled="true"
>   sslDefaultHost="vgcspsteste1.rpega.com">
>
>certificateKeystoreFile="D:\certificates\ourcert.keystore" 
> certificateKeystorePassword="***" certificateKeyAlias="ourAlias" 
> type="RSA"/>
>
>   
> An example of the error looks like the below:
> 23 Jun 2016 01:28:39,731 [sl-nio2-8443-exec-11] 
> (ngineinterface.service.HttpAPI) ERROR: Error adopting XML from post data 
> com.pega.pegarules.pub.clipboard.InvalidStreamError: InvalidStream  
> com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(String, 
> StorageStream)   sax parse error: Content is not allowed in prolog.
> From: (H64E3757ED751A9AEE78817056219F4F9:10.224.243.66)
>   at 
> com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:477)
>   at 
> com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:432)
>   at 
> com.pega.pegarules.data.internal.clipboard.ClipboardPageImpl.adoptXMLForm(ClipboardPageImpl.java:818)
>   at 
> com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.mapInputData(HttpAPI.java:2481)
>   at 
> com.pega.pegarules.session.external.engineinterface.service.EngineAPI.activityExecutionProlog(EngineAPI.java:554)
>   at 
> com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequestInner(EngineAPI.java:388)
>   at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.pega.pegarules.session.internal.PRSessionProvi

Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

2016-07-06 Thread tomcat

On 06.07.2016 21:43, Mekkelsen Madden, Steve wrote:

I've attached a screenshot showing the request if that helps.


Unfortunately, as you may notice, this list strips most attachments.
It would thus be better if you uploaded that screenshot somewhere, and provided 
a link to it.


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



RE: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

2016-07-06 Thread Mekkelsen Madden, Steve
Thanks Felix. See below


-Original Message-
From: Felix Schumacher [mailto:felix.schumac...@internetallee.de] 
Sent: Wednesday, July 06, 2016 3:29 PM
To: users@tomcat.apache.org
Subject: Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

Am 06.07.2016 um 19:14 schrieb Mekkelsen Madden, Steve:
> This particular issue has raised a lot of issues in-house and we would 
> greatly appreciate a response from someone having more details on why NIO2 no 
> longer works.
>
> Thanks!
>
>
> -Original Message-
> From: Mekkelsen Madden, Steve
> Sent: Friday, July 01, 2016 12:56 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding 
> issues
>
> Hi all,
>
> Is anyone aware of why after upgrading from Tomcat 8.0.32x64 (Windows) to 
> 8.5.3x64 using the connector protocol of: 
> protocol="org.apache.coyote.http11.Http11Nio2Protocol"  fails with url 
> encoding errors?  Once it was changed back to 
> protocol="org.apache.coyote.http11.Http11NioProtocol" all the errors stopped. 
>  This completely broke the application and made it unusable as the xml being 
> returned was not decoded and resulted in sax parse exceptions with our AJAX 
> connections.   I haven't found anything related to the protocol changing, 
> only the parameters for the SSL/TLS attributes which are in place and work.  
> It's almost like it's blocking the requests when it should be unblocking the 
> requests?  Thanks!!
Have you tried to compare the responses, that you get through the two 
connectors? Especially the characters before the xml prolog would be 
interesting.
Do you get the same errors, when you are requesting the url without tls?

Regards,
  Felix

Steve: We did not try turning off TLS in this case since this is what was 
already enabled in Production and required due to servers being accessible 
outside the network.  What the engineer found is that Fiddler showed all XML 
content (all the strings) that is being sent to and from the server were being 
encoded.  However, the XML content in fiddler does not have the encoded 
content.  I've attached a screenshot showing the request if that helps.

>
> Database Type: Oracle 12c Linux x64
> Driver used: ojdbc7.jar
> Connector attribute:  
>protocol="org.apache.coyote.http11.Http11NioProtocol"
>   maxThreads="150" disableUploadTimeout="true"
>   SSLEnabled="true"
>   sslDefaultHost="vgcspsteste1.rpega.com">
>
>certificateKeystoreFile="D:\certificates\ourcert.keystore" 
> certificateKeystorePassword="***" certificateKeyAlias="ourAlias" 
> type="RSA"/>
>
>   
> An example of the error looks like the below:
> 23 Jun 2016 01:28:39,731 [sl-nio2-8443-exec-11] 
> (ngineinterface.service.HttpAPI) ERROR: Error adopting XML from post data 
> com.pega.pegarules.pub.clipboard.InvalidStreamError: InvalidStream  
> com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(String, 
> StorageStream)   sax parse error: Content is not allowed in prolog.
> From: (H64E3757ED751A9AEE78817056219F4F9:10.224.243.66)
>   at 
> com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:477)
>   at 
> com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:432)
>   at 
> com.pega.pegarules.data.internal.clipboard.ClipboardPageImpl.adoptXMLForm(ClipboardPageImpl.java:818)
>   at 
> com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.mapInputData(HttpAPI.java:2481)
>   at 
> com.pega.pegarules.session.external.engineinterface.service.EngineAPI.activityExecutionProlog(EngineAPI.java:554)
>   at 
> com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequestInner(EngineAPI.java:388)
>   at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> com.pega.pegarules.session.internal.PRSessionProviderImpl.performTargetActionWithLock(PRSessionProviderImpl.java:1277)
>   at 
> com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:1015)
>   at 
> com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:848)
>   at 
> com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequest(EngineAPI.java:331)
>   at 
> com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.invoke(HttpAPI.java:817)
> 

Re: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

2016-07-06 Thread Felix Schumacher

Am 06.07.2016 um 19:14 schrieb Mekkelsen Madden, Steve:

This particular issue has raised a lot of issues in-house and we would greatly 
appreciate a response from someone having more details on why NIO2 no longer 
works.

Thanks!


-Original Message-
From: Mekkelsen Madden, Steve
Sent: Friday, July 01, 2016 12:56 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

Hi all,

Is anyone aware of why after upgrading from Tomcat 8.0.32x64 (Windows) to 8.5.3x64 using the 
connector protocol of: protocol="org.apache.coyote.http11.Http11Nio2Protocol"  fails with 
url encoding errors?  Once it was changed back to 
protocol="org.apache.coyote.http11.Http11NioProtocol" all the errors stopped.  This 
completely broke the application and made it unusable as the xml being returned was not decoded and 
resulted in sax parse exceptions with our AJAX connections.   I haven't found anything related to 
the protocol changing, only the parameters for the SSL/TLS attributes which are in place and work.  
It's almost like it's blocking the requests when it should be unblocking the requests?  Thanks!!
Have you tried to compare the responses, that you get through the two 
connectors? Especially the characters before the xml prolog would be 
interesting.

Do you get the same errors, when you are requesting the url without tls?

Regards,
 Felix


Database Type: Oracle 12c Linux x64
Driver used: ojdbc7.jar
Connector attribute:

 

 

An example of the error looks like the below:
23 Jun 2016 01:28:39,731 [sl-nio2-8443-exec-11] 
(ngineinterface.service.HttpAPI) ERROR: Error adopting XML from post data 
com.pega.pegarules.pub.clipboard.InvalidStreamError: InvalidStream
com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(String, 
StorageStream)   sax parse error: Content is not allowed in prolog.
From: (H64E3757ED751A9AEE78817056219F4F9:10.224.243.66)
at 
com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:477)
at 
com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:432)
at 
com.pega.pegarules.data.internal.clipboard.ClipboardPageImpl.adoptXMLForm(ClipboardPageImpl.java:818)
at 
com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.mapInputData(HttpAPI.java:2481)
at 
com.pega.pegarules.session.external.engineinterface.service.EngineAPI.activityExecutionProlog(EngineAPI.java:554)
at 
com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequestInner(EngineAPI.java:388)
at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.performTargetActionWithLock(PRSessionProviderImpl.java:1277)
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:1015)
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:848)
at 
com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequest(EngineAPI.java:331)
at 
com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.invoke(HttpAPI.java:817)
at 
com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl._invokeEngine_privact(EngineImpl.java:327)
at 
com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl.invokeEngine(EngineImpl.java:270)
at 
com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl.invokeEngine(EngineImpl.java:247)
at 
com.pega.pegarules.priv.context.JNDIEnvironment.invokeEngineInner(JNDIEnvironment.java:278)
at 
com.pega.pegarules.priv.context.JNDIEnvironment.invokeEngine(JNDIEnvironment.java:223)
at 
com.pega.pegarules.web.impl.WebStandardImpl.makeEtierRequest(WebStandardImpl.java:574)
at 
com.pega.pegarules.web.impl.WebStandardImpl.doPost(WebStandardImpl.java:374)
at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethod(PRBootstrap.java:338)
at 
com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethodPropagatingThrowable(PRBootstrap.java:379)
at 
com.pega.pegarules.boot.internal.extbridge.AppServerBridgeToPega.invokeMethodPropagatingThrowable(AppServerBridgeToPega.java:216)
at 
com.pega.pegarules.boot.internal.extbridge.AppServerBridgeToPega.invokeMethod(AppS

RE: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

2016-07-06 Thread Mekkelsen Madden, Steve
This particular issue has raised a lot of issues in-house and we would greatly 
appreciate a response from someone having more details on why NIO2 no longer 
works.

Thanks!


-Original Message-
From: Mekkelsen Madden, Steve 
Sent: Friday, July 01, 2016 12:56 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

Hi all,

Is anyone aware of why after upgrading from Tomcat 8.0.32x64 (Windows) to 
8.5.3x64 using the connector protocol of: 
protocol="org.apache.coyote.http11.Http11Nio2Protocol"  fails with url encoding 
errors?  Once it was changed back to 
protocol="org.apache.coyote.http11.Http11NioProtocol" all the errors stopped.  
This completely broke the application and made it unusable as the xml being 
returned was not decoded and resulted in sax parse exceptions with our AJAX 
connections.   I haven't found anything related to the protocol changing, only 
the parameters for the SSL/TLS attributes which are in place and work.  It's 
almost like it's blocking the requests when it should be unblocking the 
requests?  Thanks!!

Database Type: Oracle 12c Linux x64
Driver used: ojdbc7.jar
Connector attribute: 

 

 

An example of the error looks like the below:
23 Jun 2016 01:28:39,731 [sl-nio2-8443-exec-11] 
(ngineinterface.service.HttpAPI) ERROR: Error adopting XML from post data 
com.pega.pegarules.pub.clipboard.InvalidStreamError: InvalidStream
com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(String, 
StorageStream)   sax parse error: Content is not allowed in prolog.
From: (H64E3757ED751A9AEE78817056219F4F9:10.224.243.66) 
at 
com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:477)
at 
com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:432)
at 
com.pega.pegarules.data.internal.clipboard.ClipboardPageImpl.adoptXMLForm(ClipboardPageImpl.java:818)
at 
com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.mapInputData(HttpAPI.java:2481)
at 
com.pega.pegarules.session.external.engineinterface.service.EngineAPI.activityExecutionProlog(EngineAPI.java:554)
at 
com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequestInner(EngineAPI.java:388)
at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.performTargetActionWithLock(PRSessionProviderImpl.java:1277)
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:1015)
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:848)
at 
com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequest(EngineAPI.java:331)
at 
com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.invoke(HttpAPI.java:817)
at 
com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl._invokeEngine_privact(EngineImpl.java:327)
at 
com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl.invokeEngine(EngineImpl.java:270)
at 
com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl.invokeEngine(EngineImpl.java:247)
at 
com.pega.pegarules.priv.context.JNDIEnvironment.invokeEngineInner(JNDIEnvironment.java:278)
at 
com.pega.pegarules.priv.context.JNDIEnvironment.invokeEngine(JNDIEnvironment.java:223)
at 
com.pega.pegarules.web.impl.WebStandardImpl.makeEtierRequest(WebStandardImpl.java:574)
at 
com.pega.pegarules.web.impl.WebStandardImpl.doPost(WebStandardImpl.java:374)
at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethod(PRBootstrap.java:338)
at 
com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethodPropagatingThrowable(PRBootstrap.java:379)
at 
com.pega.pegarules.boot.internal.extbridge.AppServerBridgeToPega.invokeMethodPropagatingThrowable(AppServerBridgeToPega.java:216)
at 
com.pega.pegarules.boot.internal.extbridge.AppServerBridgeToPega.invokeMethod(AppServerBridgeToPega.java:265)
at 
com.pega.pegarules.internal.web.servlet.WebStandardBoot.doPost(WebStandardBoot.java:118)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at 
org.apache.catalina.core.ApplicationFi

SSL/TLS 8.5.3 upgrade from 8.0.32 using NIO2 url encoding issues

2016-07-01 Thread Mekkelsen Madden, Steve
Hi all,

Is anyone aware of why after upgrading from Tomcat 8.0.32x64 (Windows) to 
8.5.3x64 using the connector protocol of: 
protocol="org.apache.coyote.http11.Http11Nio2Protocol"  fails with url encoding 
errors?  Once it was changed back to 
protocol="org.apache.coyote.http11.Http11NioProtocol" all the errors stopped.  
This completely broke the application and made it unusable as the xml being 
returned was not decoded and resulted in sax parse exceptions with our AJAX 
connections.   I haven't found anything related to the protocol changing, only 
the parameters for the SSL/TLS attributes which are in place and work.  It's 
almost like it's blocking the requests when it should be unblocking the 
requests?  Thanks!!

Database Type: Oracle 12c Linux x64
Driver used: ojdbc7.jar
Connector attribute: 

 

 

An example of the error looks like the below:
23 Jun 2016 01:28:39,731 [sl-nio2-8443-exec-11] 
(ngineinterface.service.HttpAPI) ERROR: Error adopting XML from post data 
com.pega.pegarules.pub.clipboard.InvalidStreamError: InvalidStream
com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(String, 
StorageStream)   sax parse error: Content is not allowed in prolog.
From: (H64E3757ED751A9AEE78817056219F4F9:10.224.243.66) 
at 
com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:477)
at 
com.pega.pegarules.data.internal.clipboard.XMLStream.newStream(XMLStream.java:432)
at 
com.pega.pegarules.data.internal.clipboard.ClipboardPageImpl.adoptXMLForm(ClipboardPageImpl.java:818)
at 
com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.mapInputData(HttpAPI.java:2481)
at 
com.pega.pegarules.session.external.engineinterface.service.EngineAPI.activityExecutionProlog(EngineAPI.java:554)
at 
com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequestInner(EngineAPI.java:388)
at sun.reflect.GeneratedMethodAccessor90.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.performTargetActionWithLock(PRSessionProviderImpl.java:1277)
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:1015)
at 
com.pega.pegarules.session.internal.PRSessionProviderImpl.doWithRequestorLocked(PRSessionProviderImpl.java:848)
at 
com.pega.pegarules.session.external.engineinterface.service.EngineAPI.processRequest(EngineAPI.java:331)
at 
com.pega.pegarules.session.internal.engineinterface.service.HttpAPI.invoke(HttpAPI.java:817)
at 
com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl._invokeEngine_privact(EngineImpl.java:327)
at 
com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl.invokeEngine(EngineImpl.java:270)
at 
com.pega.pegarules.session.internal.engineinterface.etier.impl.EngineImpl.invokeEngine(EngineImpl.java:247)
at 
com.pega.pegarules.priv.context.JNDIEnvironment.invokeEngineInner(JNDIEnvironment.java:278)
at 
com.pega.pegarules.priv.context.JNDIEnvironment.invokeEngine(JNDIEnvironment.java:223)
at 
com.pega.pegarules.web.impl.WebStandardImpl.makeEtierRequest(WebStandardImpl.java:574)
at 
com.pega.pegarules.web.impl.WebStandardImpl.doPost(WebStandardImpl.java:374)
at sun.reflect.GeneratedMethodAccessor89.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethod(PRBootstrap.java:338)
at 
com.pega.pegarules.internal.bootstrap.PRBootstrap.invokeMethodPropagatingThrowable(PRBootstrap.java:379)
at 
com.pega.pegarules.boot.internal.extbridge.AppServerBridgeToPega.invokeMethodPropagatingThrowable(AppServerBridgeToPega.java:216)
at 
com.pega.pegarules.boot.internal.extbridge.AppServerBridgeToPega.invokeMethod(AppServerBridgeToPega.java:265)
at 
com.pega.pegarules.internal.web.servlet.WebStandardBoot.doPost(WebStandardBoot.java:118)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
at 
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
at 
org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at 
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
at 
org.apache.catalina.core.Application

Re: backslash URL encoding

2013-05-09 Thread Lutischán Ferenc

Dear Dan,

Thanks for your suggestion.
I tried it, but it didn't work for me (Tomcat started with parameter: 
-Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true).

In my tomcat log:
127.0.0.1 - - [09/May/2013:15:34:54 +0200] GET 
/angol-magyar-szotar/w%5C HTTP/1.1 400 -


Regards,
Ferenc

 Dear Dan,

 Thank for your reply.

 1. This site is a dictionary:
 - Windows users often enter a \ in place of /
 - Rarely there are \ in the phrases

I think what you're looking for is this...

org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true

https://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security 
https://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security

If you set it to true, it should allow '%2F' and '%5C' in your URL.

This has security implications though.  Please read the following link 
for CVE-2007-0450.


https://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.10 
https://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.10


Dan

On May 8, 2013, at 9:09 AM, Lutischán Ferenc wrote:

 Dear Dan,

 Thank for your reply.

 1. This site is a dictionary:
 - Windows users often enter a \ in place of /
 - Rarely there are \ in the phrases

I think what you're looking for is this...

org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true

https://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security 
https://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security

If you set it to true, it should allow '%2F' and '%5C' in your URL.

This has security implications though.  Please read the following link 
for CVE-2007-0450.


https://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.10 
https://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.10


Dan

On May 8, 2013, at 8:46 AM, Lutischán Ferenc wrote:

Dear Users,

Tomcat 7.0.39.

I have problem with the following url in firefox 20:
http://dictzone.com/english-german-dictionary/a\  (it resulted in 
thehttp://dictzone.com/english-german-dictionary/a%5C  request).

Why do you have a \ on the end of the URL?  Is that intentional?  Does it 
work if you remove it?


It results is an emtpy page.

What is the HTTP Status code being returned with the request?  4xx?  5xx?



This request don't arrive my servelt / filter codes.

Please include your servlet mapping from web.xml.


Dan



How to fix it?

Regards,
 Ferenc

-
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






Re: backslash URL encoding

2013-05-09 Thread Daniel Mikusa
On May 9, 2013, at 11:05 AM, Lutischán Ferenc wrote:

 Dear Dan,
 
 Thanks for your suggestion.
 I tried it, but it didn't work for me (Tomcat started with parameter: 
 -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true).
 In my tomcat log:
 127.0.0.1 - - [09/May/2013:15:34:54 +0200] GET /angol-magyar-szotar/w%5C 
 HTTP/1.1 400 -

My fault, I think that you need this option as well.

-Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=true

I tried setting both to true and it worked for me.

Dan

 Regards,
Ferenc
 
  Dear Dan,
 
  Thank for your reply.
 
  1. This site is a dictionary:
  - Windows users often enter a \ in place of /
  - Rarely there are \ in the phrases
 
 I think what you're looking for is this...
 
 org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true
 
 https://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security 
 https://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security
 
 If you set it to true, it should allow '%2F' and '%5C' in your URL.
 
 This has security implications though.  Please read the following link for 
 CVE-2007-0450.
 
 https://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.10 
 https://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.10
 
 Dan
 
 On May 8, 2013, at 9:09 AM, Lutischán Ferenc wrote:
 
  Dear Dan,
 
  Thank for your reply.
 
  1. This site is a dictionary:
  - Windows users often enter a \ in place of /
  - Rarely there are \ in the phrases
 
 I think what you're looking for is this...
 
 org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true
 
 https://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security 
 https://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security
 
 If you set it to true, it should allow '%2F' and '%5C' in your URL.
 
 This has security implications though.  Please read the following link for 
 CVE-2007-0450.
 
 https://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.10 
 https://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.10
 
 Dan
 
 On May 8, 2013, at 8:46 AM, Lutischán Ferenc wrote:
 Dear Users,
 
 Tomcat 7.0.39.
 
 I have problem with the following url in firefox 20:
 http://dictzone.com/english-german-dictionary/a\  (it resulted in 
 thehttp://dictzone.com/english-german-dictionary/a%5C  request).
 Why do you have a \ on the end of the URL?  Is that intentional?  Does it 
 work if you remove it?
 
 It results is an emtpy page.
 What is the HTTP Status code being returned with the request?  4xx?  5xx?
 
 
 This request don't arrive my servelt / filter codes.
 Please include your servlet mapping from web.xml.
 
 
 Dan
 
 
 How to fix it?
 
 Regards,
 Ferenc
 
 -
 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
 
 
 


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



backslash URL encoding

2013-05-08 Thread Lutischán Ferenc

Dear Users,

Tomcat 7.0.39.

I have problem with the following url in firefox 20:
http://dictzone.com/english-german-dictionary/a\ (it resulted in the 
http://dictzone.com/english-german-dictionary/a%5C request).


It results is an emtpy page. This request don't arrive my servelt / 
filter codes.


How to fix it?

Regards,
 Ferenc

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



Re: backslash URL encoding

2013-05-08 Thread Daniel Mikusa

On May 8, 2013, at 8:46 AM, Lutischán Ferenc wrote:

 Dear Users,
 
 Tomcat 7.0.39.
 
 I have problem with the following url in firefox 20:
 http://dictzone.com/english-german-dictionary/a\ (it resulted in the 
 http://dictzone.com/english-german-dictionary/a%5C request).

Why do you have a \ on the end of the URL?  Is that intentional?  Does it 
work if you remove it?

 
 It results is an emtpy page.

What is the HTTP Status code being returned with the request?  4xx?  5xx?


 This request don't arrive my servelt / filter codes.

Please include your servlet mapping from web.xml.  


Dan


 
 How to fix it?
 
 Regards,
 Ferenc
 
 -
 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



Re: backslash URL encoding

2013-05-08 Thread Lutischán Ferenc

Dear Dan,

Thank for your reply.

1. This site is a dictionary:
- Windows users often enter a \ in place of /
- Rarely there are \ in the phrases

2. The returned status code is: 400 Bad Request

3. Mappings:
servlet
servlet-nameindex/servlet-name
servlet-classcom.ys.dictzone.Index/servlet-class
/servlet
servlet-mapping
servlet-nameindex/servlet-name
url-pattern/*/url-pattern
/servlet-mapping
servlet-mapping
servlet-nameerror404/servlet-name
url-pattern/error404/url-pattern
/servlet-mapping
servlet-mapping
servlet-nameerror500/servlet-name
url-pattern/error500/url-pattern
/servlet-mapping
filter
filter-nameSimpleCachingHeadersPageCachingFilter/filter-name
filter-classcom.ys.cache.GzipCachingFilter/filter-class
init-param
param-namesuppressStackTrace/param-name
param-valuefalse/param-value
/init-param
/filter
filter-mapping
filter-nameSimpleCachingHeadersPageCachingFilter/filter-name
url-pattern/*/url-pattern
/filter-mapping

Regards,
  Ferenc


2013.05.08. 14:53 keltezéssel, Daniel Mikusa írta:

On May 8, 2013, at 8:46 AM, Lutischán Ferenc wrote:


Dear Users,

Tomcat 7.0.39.

I have problem with the following url in firefox 20:
http://dictzone.com/english-german-dictionary/a\ (it resulted in the 
http://dictzone.com/english-german-dictionary/a%5C request).

Why do you have a \ on the end of the URL?  Is that intentional?  Does it 
work if you remove it?


It results is an emtpy page.

What is the HTTP Status code being returned with the request?  4xx?  5xx?



This request don't arrive my servelt / filter codes.

Please include your servlet mapping from web.xml.


Dan



How to fix it?

Regards,
 Ferenc

-
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





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



Re: backslash URL encoding

2013-05-08 Thread Daniel Mikusa
On May 8, 2013, at 9:09 AM, Lutischán Ferenc wrote:

 Dear Dan,
 
 Thank for your reply.
 
 1. This site is a dictionary:
 - Windows users often enter a \ in place of /
 - Rarely there are \ in the phrases

I think what you're looking for is this…

  org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true


https://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security

If you set it to true, it should allow '%2F' and '%5C' in your URL.

This has security implications though.  Please read the following link for 
CVE-2007-0450.

 https://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.10

Dan


 
 2. The returned status code is: 400 Bad Request
 
 3. Mappings:
servlet
servlet-nameindex/servlet-name
 servlet-classcom.ys.dictzone.Index/servlet-class
/servlet
servlet-mapping
servlet-nameindex/servlet-name
url-pattern/*/url-pattern
/servlet-mapping
servlet-mapping
servlet-nameerror404/servlet-name
url-pattern/error404/url-pattern
/servlet-mapping
servlet-mapping
servlet-nameerror500/servlet-name
url-pattern/error500/url-pattern
/servlet-mapping
filter
 filter-nameSimpleCachingHeadersPageCachingFilter/filter-name
 filter-classcom.ys.cache.GzipCachingFilter/filter-class
init-param
 param-namesuppressStackTrace/param-name
param-valuefalse/param-value
/init-param
/filter
filter-mapping
 filter-nameSimpleCachingHeadersPageCachingFilter/filter-name
url-pattern/*/url-pattern
/filter-mapping
 
 Regards,
  Ferenc
 
 
 2013.05.08. 14:53 keltezéssel, Daniel Mikusa írta:
 On May 8, 2013, at 8:46 AM, Lutischán Ferenc wrote:
 
 Dear Users,
 
 Tomcat 7.0.39.
 
 I have problem with the following url in firefox 20:
 http://dictzone.com/english-german-dictionary/a\ (it resulted in the 
 http://dictzone.com/english-german-dictionary/a%5C request).
 Why do you have a \ on the end of the URL?  Is that intentional?  Does it 
 work if you remove it?
 
 It results is an emtpy page.
 What is the HTTP Status code being returned with the request?  4xx?  5xx?
 
 
 This request don't arrive my servelt / filter codes.
 Please include your servlet mapping from web.xml.
 
 
 Dan
 
 
 How to fix it?
 
 Regards,
 Ferenc
 
 -
 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
 
 
 
 
 -
 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



Re: related to bad url encoding?...

2011-02-22 Thread alex

alex wrote:

Mark Thomas wrote:

On 21/02/2011 04:25, alex wrote:

hi all,
I get 404 err, if I add %D0 to url, but I get just blank page if I add
%zD0 . I'm supposed to get bad request in this case. how do I fix this
problem?


Check the response headers.

If you don't see a 400 response, exactly which Tomcat version are you 
using?


Mark

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



I used 6.0.24 .
http://localhost:8080/examples/servlets/%D0 returns 404
http://localhost:8080/examples/servlets/%zD0 returns blank page



Can anyone tell me if it's a bug or a problem on my side?
thanks.


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



Re: related to bad url encoding?...

2011-02-22 Thread Mark Thomas
On 22/02/2011 13:27, alex wrote:
 alex wrote:
 Mark Thomas wrote:
 On 21/02/2011 04:25, alex wrote:
 hi all,
 I get 404 err, if I add %D0 to url, but I get just blank page if I add
 %zD0 . I'm supposed to get bad request in this case. how do I fix this
 problem?

 Check the response headers.

 If you don't see a 400 response, exactly which Tomcat version are you
 using?

 Mark

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


 I used 6.0.24 .
 http://localhost:8080/examples/servlets/%D0 returns 404
 http://localhost:8080/examples/servlets/%zD0 returns blank page


 Can anyone tell me if it's a bug or a problem on my side?
 thanks.

Again, look at the response *headers*.

Mark

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



Re: related to bad url encoding?...

2011-02-22 Thread alex

Mark Thomas wrote:

On 22/02/2011 13:27, alex wrote:

alex wrote:

Mark Thomas wrote:

On 21/02/2011 04:25, alex wrote:

hi all,
I get 404 err, if I add %D0 to url, but I get just blank page if I add
%zD0 . I'm supposed to get bad request in this case. how do I fix this
problem?

Check the response headers.

If you don't see a 400 response, exactly which Tomcat version are you
using?

Mark

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


I used 6.0.24 .
http://localhost:8080/examples/servlets/%D0 returns 404
http://localhost:8080/examples/servlets/%zD0 returns blank page



Can anyone tell me if it's a bug or a problem on my side?
thanks.


Again, look at the response *headers*.

Mark

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



Mark,
it does return 400 code, but in my app I set:
...
   error-page
error-code400/error-code
location/WEB-INF/error.jsp/location
  /error-page
   error-page
error-code404/error-code
location/WEB-INF/error.jsp/location
  /error-page
.

and tomcat doesn't show it. this custom err page is shown for 404 code, 
but not for 400...

Can you give me a hint why?
thanks again.








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



Re: related to bad url encoding?...

2011-02-22 Thread André Warnier

alex wrote:

Mark Thomas wrote:

On 22/02/2011 13:27, alex wrote:

alex wrote:

Mark Thomas wrote:

On 21/02/2011 04:25, alex wrote:

hi all,
I get 404 err, if I add %D0 to url, but I get just blank page if I 
add
%zD0 . I'm supposed to get bad request in this case. how do I fix 
this

problem?

Check the response headers.

If you don't see a 400 response, exactly which Tomcat version are you
using?

Mark

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


I used 6.0.24 .
http://localhost:8080/examples/servlets/%D0 returns 404
http://localhost:8080/examples/servlets/%zD0 returns blank page



Can anyone tell me if it's a bug or a problem on my side?
thanks.


Again, look at the response *headers*.

Mark

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



Mark,
it does return 400 code, but in my app I set:
...
   error-page
error-code400/error-code
location/WEB-INF/error.jsp/location
  /error-page
   error-page
error-code404/error-code
location/WEB-INF/error.jsp/location
  /error-page
.

and tomcat doesn't show it. this custom err page is shown for 404 code, 
but not for 400...

Can you give me a hint why?
thanks again.


probably because :
because of the bad URL, Tomcat never even maps this call to your application, so it 
sends its own 400 error page (as Konstantin already explained, I believe).



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



Re: related to bad url encoding?...

2011-02-22 Thread alex

André Warnier wrote:

alex wrote:

Mark Thomas wrote:

On 22/02/2011 13:27, alex wrote:

alex wrote:

Mark Thomas wrote:

On 21/02/2011 04:25, alex wrote:

hi all,
I get 404 err, if I add %D0 to url, but I get just blank page if 
I add
%zD0 . I'm supposed to get bad request in this case. how do I fix 
this

problem?

Check the response headers.

If you don't see a 400 response, exactly which Tomcat version are you
using?

Mark

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


I used 6.0.24 .
http://localhost:8080/examples/servlets/%D0 returns 404
http://localhost:8080/examples/servlets/%zD0 returns blank page



Can anyone tell me if it's a bug or a problem on my side?
thanks.


Again, look at the response *headers*.

Mark

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



Mark,
it does return 400 code, but in my app I set:
...
   error-page
error-code400/error-code
location/WEB-INF/error.jsp/location
  /error-page
   error-page
error-code404/error-code
location/WEB-INF/error.jsp/location
  /error-page
.

and tomcat doesn't show it. this custom err page is shown for 404 
code, but not for 400...

Can you give me a hint why?
thanks again.


probably because :
because of the bad URL, Tomcat never even maps this call to your 
application, 


shouldn't it be 404 error if tomcat can't map this call?



so it sends its own 400 error page (as Konstantin already  explained, I 
believe).





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



RE: related to bad url encoding?...

2011-02-22 Thread Caldarale, Charles R
 From: alex [mailto:alex.alex.alex.9...@gmail.com] 
 Subject: Re: related to bad url encoding?...

 shouldn't it be 404 error if tomcat can't map this call?

Tomcat 7 has introduced revised handling for situations where there is no ROOT 
webapp; you might want to try that.  Regardless, you still can only use a 
custom error page on a mapping failure if you've got a default webapp (ROOT) 
and configure ROOT's WEB-INF/web.xml for it.

 - Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


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



Re: related to bad url encoding?...

2011-02-22 Thread Mark Thomas
On 22/02/2011 17:26, Caldarale, Charles R wrote:
 From: alex [mailto:alex.alex.alex.9...@gmail.com] 
 Subject: Re: related to bad url encoding?...
 
 shouldn't it be 404 error if tomcat can't map this call?
 
 Tomcat 7 has introduced revised handling for situations where there is no 
 ROOT webapp; you might want to try that.  Regardless, you still can only use 
 a custom error page on a mapping failure if you've got a default webapp 
 (ROOT) and configure ROOT's WEB-INF/web.xml for it.

It isn't going to help in this case. The URL is not valid so it is
correctly rejected by the connector with a 400 response. Since the URL
is invalid, it can't reliably be used to map it to a web application so
there is no opportunity to use an application generated/supplied error page.

Mark

PS The change in 7 just returns a 404 rather than a 400 for requests to
/ when there is no ROOT web application defined.


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



Re: related to bad url encoding?...

2011-02-22 Thread alex

Mark Thomas wrote:

On 22/02/2011 17:26, Caldarale, Charles R wrote:
From: alex [mailto:alex.alex.alex.9...@gmail.com] 
Subject: Re: related to bad url encoding?...

shouldn't it be 404 error if tomcat can't map this call?

Tomcat 7 has introduced revised handling for situations where there is no ROOT 
webapp; you might want to try that.  Regardless, you still can only use a 
custom error page on a mapping failure if you've got a default webapp (ROOT) 
and configure ROOT's WEB-INF/web.xml for it.


It isn't going to help in this case. The URL is not valid so it is
correctly rejected by the connector with a 400 response. Since the URL
is invalid, it can't reliably be used to map it to a web application so
there is no opportunity to use an application generated/supplied error page.


so, what do I do if I need to show error in this scenario and I run 
standalone tomcat?
can I do it in custom filter/connector or the only solution to place 
tomcat behind apache?






Mark

PS The change in 7 just returns a 404 rather than a 400 for requests to
/ when there is no ROOT web application defined.





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



Re: related to bad url encoding?...

2011-02-22 Thread Mark Thomas
On 22/02/2011 21:36, alex wrote:
 Mark Thomas wrote:
 On 22/02/2011 17:26, Caldarale, Charles R wrote:
 From: alex [mailto:alex.alex.alex.9...@gmail.com] Subject: Re:
 related to bad url encoding?...
 shouldn't it be 404 error if tomcat can't map this call?
 Tomcat 7 has introduced revised handling for situations where there
 is no ROOT webapp; you might want to try that.  Regardless, you still
 can only use a custom error page on a mapping failure if you've got a
 default webapp (ROOT) and configure ROOT's WEB-INF/web.xml for it.

 It isn't going to help in this case. The URL is not valid so it is
 correctly rejected by the connector with a 400 response. Since the URL
 is invalid, it can't reliably be used to map it to a web application so
 there is no opportunity to use an application generated/supplied error
 page.
 
 so, what do I do if I need to show error in this scenario and I run
 standalone tomcat?
 can I do it in custom filter/connector or the only solution to place
 tomcat behind apache?

A filter is too late in the chain, as is a valve. A custom connector
code seems like overkill for this. I would probably go with httpd myself.

There may be a way to get the request to be forwarded to the default
host where the default error handler could respond but I suspect that
approach could quickly get messy. One of the reasons for rejected the
requests in the connector was performance.

Mark

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



Re: related to bad url encoding?...

2011-02-22 Thread André Warnier

alex wrote:
...



so, what do I do if I need to show error in this scenario and I run 
standalone tomcat?

...

It seems to me that by the 400 status code, the error is already shown, 
correctly.
Tomcat is doing the minimum, but it is doing it according to the RFC.

HTTP RFC 2616 says:

10.4 Client Error 4xx

The 4xx class of status code is intended for cases in which the client seems to 
have erred.
Except when responding to a HEAD request, the server SHOULD include an entity 
containing
an explanation of the error situation, and whether it is a temporary or 
permanent condition.
These status codes are applicable to any request method. User agents SHOULD display any 
included entity to the user.

...

(Notice SHOULD, not MUST).

10.4.1 400 Bad Request
The request could not be understood by the server due to malformed syntax.
The client SHOULD NOT repeat the request without modifications.

(This thus seems to be the appropriate status code. After all, the client /did/ send a 
malformed URL.)


(In any case, none of the other ones seems to fit.)

10.4.2 401 Unauthorized
10.4.3 402 Payment Required
10.4.4 403 Forbidden
10.4.5 404 Not Found
10.4.6 405 Method Not Allowed
10.4.7 406 Not Acceptable
10.4.8 407 Proxy Authentication Required
10.4.9 408 Request Timeout
10.4.10 409 Conflict
10.4.11 410 Gone
10.4.12 411 Length Required
10.4.13 412 Precondition Failed
10.4.14 413 Request Entity Too Large
10.4.15 414 Request-URI Too Long
10.4.16 415 Unsupported Media Type
10.4.17 416 Requested Range Not Satisfiable
10.4.18 417 Expectation Failed


Re: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html


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



Re: related to bad url encoding?...

2011-02-21 Thread Mark Thomas
On 21/02/2011 04:25, alex wrote:
 hi all,
 I get 404 err, if I add %D0 to url, but I get just blank page if I add
 %zD0 . I'm supposed to get bad request in this case. how do I fix this
 problem?

Check the response headers.

If you don't see a 400 response, exactly which Tomcat version are you using?

Mark

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



Re: related to bad url encoding?...

2011-02-21 Thread alex

Mark Thomas wrote:

On 21/02/2011 04:25, alex wrote:

hi all,
I get 404 err, if I add %D0 to url, but I get just blank page if I add
%zD0 . I'm supposed to get bad request in this case. how do I fix this
problem?


Check the response headers.

If you don't see a 400 response, exactly which Tomcat version are you using?

Mark

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



I used 6.0.24 .
http://localhost:8080/examples/servlets/%D0 returns 404
http://localhost:8080/examples/servlets/%zD0 returns blank page



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



related to bad url encoding?...

2011-02-20 Thread alex

hi all,
I get 404 err, if I add %D0 to url, but I get just blank page if I add 
%zD0 . I'm supposed to get bad request in this case. how do I fix this 
problem?



thanks.

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



RE: URL encoding problem IIS6 / JK1.2.25 / Tomcat 5.5.20

2008-06-25 Thread Jesse Klaasse
André Warnier wrote:

It would appear (from the logs), that there is some double-encoding of the URI 
going on.
[snip]
But, if somewhere along the line, a piece of code was receiving the encoded 
URI http://.../test%5Bbrackets%5D.jsp;, and decided to re-encode it again 
using the % hex hex method, then you would get this URI : 
http://.../test%255Bbrackets%255D.jsp; (where %25 is the encoded version of 
%).
Then the next step would decode this URI back into 
http://.../test%5Bbrackets%5D.jsp;, and that is what the server would try to 
access, what would be logged, and also what you seem to experience.

So, which is the culprit which re-encodes something it should not ?
And is there not some parameter somewhere which forces it to do so ?

Thanks for your excellent answer. I have fixed the problem now. There is a 
setting for the isapi_redirecor called uri_select. This parameter controls 
the URI's which are passed to Tomcat from IIS. It defaults to value proxy, 
which leads to some re-encoding. I have changed the parameter's value to 
unparsed now, which has solved the problem.

For those who want to know more, the parameter is explained here: 
http://tomcat.apache.org/connectors-doc/reference/iis.html

Jesse.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: URL encoding problem IIS6 / JK1.2.25 / Tomcat 5.5.20

2008-06-25 Thread André Warnier


Jesse Klaasse wrote:
[...]

Good.
Now, I should add that using [ and ] in URL's is not really something I 
would recommend, if only for legibility reasons.  It will always make 
people wonder if what they're seeing in the logfile is normal, or if 
it's some programming syntax which escaped there.
And I would bet that naming your servlet that way is also going to bring 
you trouble if you ever have to reference it in a Javascript line for 
instance.


André


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: URL encoding problem IIS6 / JK1.2.25 / Tomcat 5.5.20

2008-06-25 Thread André Warnier


Jesse Klaasse wrote:
[...]

Good.
Now, I should add that using [ and ] in URL's is not really something I 
would recommend, if only for legibility reasons.  It will always make 
people wonder if what they're seeing in the logfile is normal, or if 
it's some programming syntax which escaped there.
And I would bet that naming your servlet that way is also going to bring 
you trouble if you ever have to reference it in a Javascript line for 
instance.


André


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: URL encoding problem IIS6 / JK1.2.25 / Tomcat 5.5.20

2008-06-25 Thread Jesse Klaasse
André Warnier wrote:
[...]
Now, I should add that using [ and ] in URL's is not really something I would 
recommend, if only for legibility reasons.  It will always make people wonder 
if what they're seeing in the logfile is normal, or if it's some programming 
syntax which escaped there.
And I would bet that naming your servlet that way is also going to bring you 
trouble if you ever have to reference it in a Javascript line for instance.

I completely agree with you when you're saying [ and ] are not recommended in 
URL's. However, I don't really have a say in that, something to do with 
politics and legacy stuff.. Thanks again for your help!

Jesse.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



URL encoding problem IIS6 / JK1.2.25 / Tomcat 5.5.20

2008-06-24 Thread Jesse Klaasse
I have recently migrated a production server from IIS5 / Resin 3.0.14 to
IIS6 / JK1.2.25 / Tomcat 5.5.20. Now, there seems to be a problem with
the URL translation from IIS to Tomcat.

I have this file in a webapp, called test[brackets].jsp.
When I try http://localhost:8080/webapp/test[brackets].jsp, everything
is working fine. So Tomcat understands the square brackets (appearing in
the Tomcat access log as test[brackets].jsp).

I have also a plain HTML file, called test[brackets].html.
When I try http://localhost/test[brackets].html, it's also working. IIS
by itself understands the square brackets, too.

Now, we try the whole link through the JK connector:
http://localhost/webapp/test[brackets].jsp
This doesn't work, and results in a 404 error (appearing in both IIS and
Tomcat's log as test%5Bbrackets%5D.jsp, Tomcat with a 404, IIS with a
200).

So, there seems to be SOMETHING wrong with the connector (or the
connector configuration) in combination with special characters. When I
try the same with a file called test.jsp, everything is working fine.

The Connector tag in server.xml doesn't have any of the encoding
attributes specified, so default encoding is used. Furthermore, the
uri_select key hasn't been set for the Isapi Redirector, so I guess
default mode (proxy) is used.

Anyone? Thanks in advance! Kind regards, Jesse Klaasse.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: URL encoding problem IIS6 / JK1.2.25 / Tomcat 5.5.20

2008-06-24 Thread André Warnier



Jesse Klaasse wrote:
[snip]


Now, we try the whole link through the JK connector:
http://localhost/webapp/test[brackets].jsp
This doesn't work, and results in a 404 error (appearing in both IIS and
Tomcat's log as test%5Bbrackets%5D.jsp, Tomcat with a 404, IIS with a
200).



Thanks for the excellent problem description.
It would appear (from the logs), that there is some double-encoding of 
the URI going on.


To simplify, I will assume that you are starting from a static html 
page, loaded in your browser from the local disk, and that this html 
page contains a link written as href=http://.../test[brackets].jsp;.
(Please check this. I know it seems evident, but just to make sure that 
you are not starting from a URl that already has the [ ] pre-encoded..)


I will also assume that %5B and %5D are the correct % hex hex encoding 
for the characters [ and ] respectively.


What *should* happen is :
- when you click on the link, the browser should encode it into 
http://.../test%5Bbrackets%5D.jsp; *before* sending it to the server.
That is because [ and ] are not within the acceptable ranges for 
unencoded URI characters, and it is normal.
- the server, when receiving this URL, should (immediately) decode it 
back into .../test[brackets].jsp; and that should also be what is 
processed, and logged.


But, if somewhere along the line, a piece of code was receiving the 
encoded URI http://.../test%5Bbrackets%5D.jsp;, and decided to 
re-encode it again using the % hex hex method, then you would get this 
URI : http://.../test%255Bbrackets%255D.jsp; (where %25 is the 
encoded version of %).
Then the next step would decode this URI back into 
http://.../test%5Bbrackets%5D.jsp;, and that is what the server would 
try to access, what would be logged, and also what you seem to experience.


So, which is the culprit which re-encodes something it should not ?
And is there not some parameter somewhere which forces it to do so ?

André





-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: URL encoding problem IIS6 / JK1.2.25 / Tomcat 5.5.20

2008-06-24 Thread Walter Thompson
Try taking out the square brackets from the jsp part and see if it works
without them (http://localhost/testbrackets.jsp).

Also, you shouldn't need the /webapp if Tomcat is configured correctly.
Make sure your directory structure is correct.

Walter

-Original Message-
From: Jesse Klaasse [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, June 24, 2008 2:14 AM
To: users@tomcat.apache.org
Subject: URL encoding problem IIS6 / JK1.2.25 / Tomcat 5.5.20

I have recently migrated a production server from IIS5 / Resin 3.0.14 to
IIS6 / JK1.2.25 / Tomcat 5.5.20. Now, there seems to be a problem with
the URL translation from IIS to Tomcat.

I have this file in a webapp, called test[brackets].jsp.
When I try http://localhost:8080/webapp/test[brackets].jsp, everything
is working fine. So Tomcat understands the square brackets (appearing in
the Tomcat access log as test[brackets].jsp).

I have also a plain HTML file, called test[brackets].html.
When I try http://localhost/test[brackets].html, it's also working. IIS
by itself understands the square brackets, too.

Now, we try the whole link through the JK connector:
http://localhost/webapp/test[brackets].jsp
This doesn't work, and results in a 404 error (appearing in both IIS and
Tomcat's log as test%5Bbrackets%5D.jsp, Tomcat with a 404, IIS with a
200).

So, there seems to be SOMETHING wrong with the connector (or the
connector configuration) in combination with special characters. When I
try the same with a file called test.jsp, everything is working fine.

The Connector tag in server.xml doesn't have any of the encoding
attributes specified, so default encoding is used. Furthermore, the
uri_select key hasn't been set for the Isapi Redirector, so I guess
default mode (proxy) is used.

Anyone? Thanks in advance! Kind regards, Jesse Klaasse.

-
To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe,
e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



url encoding in ie6

2008-02-03 Thread John Pedersen
Hi,

I have just implemented url encoding in my app, so that it now works in
Opera, FF, IE7 with cookies either enabled or disabled. When cookies are
disabled, I get the jsessionid showing up in the url. (Most pages require
the user to be logged in ).

It doesn't work for ie6 though. With cookies disabled, I keep being sent
back to the login page.

Is there something different in the way ie6 handles sessions?

Thanks,

John


Re: Force URL encoding

2007-09-11 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael,

Michael Dehmlow wrote:
 The new session println() is called every time(even with the hack).

So, when you make a request with a URL including the jsessionid
parameter, it still gets ignored? This is one page, on one server,
right? Weird.

 which
 says to me that tc is ignoring the url encoded sessionid. I've tried every
 variation I can think of can someone point me in the direction of the
 tomcats source 8(

Try going back to cookies=true (well.. remove the cookies=false) and
try disabling cookies on your browser. Do your URLs get encoded by
Tomcat, then?

They certainly do when I turn off cookies, and I haven't done anything
weird with my configuration at all.

- -chris

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG5q5P9CaO5/Lv0PARApBXAJ44ka0IjpRfOULvhqOqaKvKc4b1bgCbB7zp
SUeNUZesUuEWeEftswe1WZU=
=w0BL
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Force URL encoding

2007-09-11 Thread Michael Dehmlow

I  ran through the source a couple of times encode url will return the
parameter in many cases there is a bunch of logic to determine if the
session is supposed to be appended,   but nothing is apparent as to why I've
been going through and trying to get a false in the logic that determines if
the URL should be encoded but I got to the end with no revalations.
I thought something might be amis due to the fact that I'm running in
calisto eclipse but putting the war into an actual tomcat enviornment
resulted in the same behavior. Scouring google I find problems relating to
https (which I'm not using) on older versions (which I'm not using).
I'll try the cookies enabled angle thanks. 




Christopher Schultz-2 wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Michael,
 
 Michael Dehmlow wrote:
 The new session println() is called every time(even with the hack).
 
 So, when you make a request with a URL including the jsessionid
 parameter, it still gets ignored? This is one page, on one server,
 right? Weird.
 
 which
 says to me that tc is ignoring the url encoded sessionid. I've tried
 every
 variation I can think of can someone point me in the direction of the
 tomcats source 8(
 
 Try going back to cookies=true (well.. remove the cookies=false) and
 try disabling cookies on your browser. Do your URLs get encoded by
 Tomcat, then?
 
 They certainly do when I turn off cookies, and I haven't done anything
 weird with my configuration at all.
 
 - -chris
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.7 (MingW32)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
 
 iD8DBQFG5q5P9CaO5/Lv0PARApBXAJ44ka0IjpRfOULvhqOqaKvKc4b1bgCbB7zp
 SUeNUZesUuEWeEftswe1WZU=
 =w0BL
 -END PGP SIGNATURE-
 
 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 
 

-- 
View this message in context: 
http://www.nabble.com/Force-URL-encoding-tf4415223.html#a12618863
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Force URL encoding

2007-09-10 Thread Michael Dehmlow

Hello I'm looking for a way to force url session tracking regardless of
whether the user has  cookies enabled. My thoughts right now are to create a
session filter that deletes the cookie on the way out the door. if this
seems like a good idea who should I go about deleting the the cookie.
-- 
View this message in context: 
http://www.nabble.com/Force-URL-encoding-tf4415223.html#a12594298
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Force URL encoding

2007-09-10 Thread Len Popp
You can just set cookies=false in the Context element in the app's
context.xml file.
See the docs for your version of Tomcat for details.
-- 
Len

On 9/10/07, Michael Dehmlow [EMAIL PROTECTED] wrote:

 Hello I'm looking for a way to force url session tracking regardless of
 whether the user has  cookies enabled. My thoughts right now are to create a
 session filter that deletes the cookie on the way out the door. if this
 seems like a good idea who should I go about deleting the the cookie.
 --
 View this message in context: 
 http://www.nabble.com/Force-URL-encoding-tf4415223.html#a12594298
 Sent from the Tomcat - User mailing list archive at Nabble.com.


 -
 To start a new topic, e-mail: users@tomcat.apache.org
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]



-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Force URL encoding

2007-09-10 Thread Michael Dehmlow

The caviot to my question was that I wanted to force session rewritting for
only one servlet. But I now see the flaw in this if another servlet in the
same context sets a cookie (jsessionid) that cookie will now be set for the
all other servlets as well. The solution is to use the cookies=false in the
context file. And simply encode all URLs.

Michael Dehmlow wrote:
 
 Hello I'm looking for a way to force url session tracking regardless of
 whether the user has  cookies enabled. My thoughts right now are to create
 a session filter that deletes the cookie on the way out the door. if this
 seems like a good idea who should I go about deleting the the cookie.
 

-- 
View this message in context: 
http://www.nabble.com/Force-URL-encoding-tf4415223.html#a12596041
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Force URL encoding

2007-09-10 Thread Michael Dehmlow

Alright now I have another problem which is baffling me:

I have:
%@ page session=true %
'%=response.encodeURL(test/) %' 
in a jsp page.
the result is always 'test/'
so i tried forcing:
'%=test;jsessionid=+request.getSession().getId() %'
And the result looks like i expect it too

But when I make another request tomcat the session I've appended.

I have a session filter which:
In my context.xml file i have:

?xml version=1.0 encoding=UTF-8 ?
Context cookies=false/Context

While the session is not stored in a cookie it appears that tomcat is not
finding the session i specify. which I think has something to do with the
fact that encodeURL does not work.

-- 
View this message in context: 
http://www.nabble.com/Force-URL-encoding-tf4415223.html#a12599331
Sent from the Tomcat - User mailing list archive at Nabble.com.


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Force URL encoding

2007-09-10 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Michael,

Michael Dehmlow wrote:
 '%=response.encodeURL(test/) %' 

This should work.

 '%=test;jsessionid=+request.getSession().getId() %'

Don't do this; find out what the problem is and fix that. I realize this
is only a test, but it's good to debug it before you replicate a hack
everywhere.

 ?xml version=1.0 encoding=UTF-8 ?
 Context cookies=false/Context
 
 While the session is not stored in a cookie

Have you verified that no cookie exchange is occurring? If you have a
cookie left over from a previous run-through, Tomcat might be using that
for session identification and therefore leaving the ;jsessionid=...
off of encoded URLs. I wouldn't be surprised if the TC code is very
tolerant of this kind of abuse, rather than simply saying okay, cookies
are disabled; we'll completely ignore them.

 it appears that tomcat is not
 finding the session i specify. which I think has something to do with the
 fact that encodeURL does not work.

If your session does not exist, then encodeURL isn't going to change
anything. Make sure that the session exists; I'm guessing that the JSP
page directive session=true ensures that?

Try purging your cookies for the test site and see if that fixes anything.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG5ax69CaO5/Lv0PARAvfLAJ4i5SqR4k4B3pXnPutXWI8XG00RkQCfacbx
VOq1VVtIZP4/jTxztVwPtzU=
=CYVf
-END PGP SIGNATURE-

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Session and URL encoding of tilde

2007-03-02 Thread Daniele Varacca

Hi there,
 my problem is as follows: I am under LINUX. When I use
explicitly the symbol ~ in the URL, tomcat keeps track correctly of
the session. When the tilde is encoded as %7e tomcat forgets the
session. And I cannot avoid this, as the sendRedirect method encodes
the tilde by default. Any ideas?

 Daniele

Now for the gory details:

There are multiple users in the system.
For every user login there is a webapp
/login/public_html/foobar, and I have set tomcat to
access it when requested at http://localhost/~login/foobar;
It works fine as long as the sendRedirect method is not used.
But once sendRedirect is called, the URL becomes
http://localhost/%7elogin/foobar; and session tracking no longer works.
I use firefox or iceweasel, with cookies enabled.

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



url encoding of % in path info part

2006-06-28 Thread Chris Searle
I seem to have some odd behaviour on tomcat 4.0.x - I know this is an
old version - we're not the only app running underneath it and one of
the others doesn't support later versions :(

We have a servlet which matches the url pattern

/html/*

In this servlet we first tracelog that we enter the doGet and then call
getPathInfo() to get the rest of the info.

Now - this works very well apart from this one issue.

If the path info part of the URL contains a %

/app/html/foo/bar+5%/baz

then tomcat (correctly as far as I can see) throws a 400 error about syntax.

So - we url encode the %

/app/html/foo/bar+5%25/baz

Now - tomcat no longer errors - nothing in catalina logs - but - the
doGet method on the servlet no longer gets called at all.

Any info on why this is happening (false assumption on my part, bug in
tomcat, bug in my code, bug in url encoding etc)?

Totally lost at this end. Encoding other chars (e.g. øæå) seems to work
just fine.

Chris


-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



mod_jk and url encoding

2005-11-15 Thread Dan Adams
Okay, i'm using tomcat 5.5 and mod_jk with apache 2. It looks like I've
got jk set up okay for the most part. I'm able to use the site as I did
before switching to mod_jk except for one thing. When I try to access
the following url I got a 404 from apache and tomcat never gets a chance
to touch the url (I have a request dump valve in there dumping all
requests):

/sdirect/_sp=Shomesp=Sadmin%2FHome/admin/Home,
$AdminBorder.$Nav.link.html

now the problem is the %2F. If I replace that with a / like this it
works fine:

/sdirect/_sp=Shomesp=Sadmin/Home/admin/Home,$AdminBorder.$Nav.link.html

I even tried adding JkOptions +ForwardUIREscaped to my httpd.conf with
no luck. Any ideas on why this is not making it to tomcat when %2F is
used?? I am really befuddled with this one.

-- 
Dan Adams
Software Engineer
Interactive Factory


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: mod_jk and url encoding

2005-11-15 Thread Dan Adams
got it. needed AllowEncodedSlashes On.

On Tue, 2005-11-15 at 14:35 -0500, Dan Adams wrote:
 Okay, i'm using tomcat 5.5 and mod_jk with apache 2. It looks like I've
 got jk set up okay for the most part. I'm able to use the site as I did
 before switching to mod_jk except for one thing. When I try to access
 the following url I got a 404 from apache and tomcat never gets a chance
 to touch the url (I have a request dump valve in there dumping all
 requests):
 
 /sdirect/_sp=Shomesp=Sadmin%2FHome/admin/Home,
 $AdminBorder.$Nav.link.html
 
 now the problem is the %2F. If I replace that with a / like this it
 works fine:
 
 /sdirect/_sp=Shomesp=Sadmin/Home/admin/Home,$AdminBorder.$Nav.link.html
 
 I even tried adding JkOptions +ForwardUIREscaped to my httpd.conf with
 no luck. Any ideas on why this is not making it to tomcat when %2F is
 used?? I am really befuddled with this one.
 
-- 
Dan Adams
Software Engineer
Interactive Factory


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



URL-Encoding Problems after Transformation from JRUN to TOMCAT

2005-10-19 Thread starki78
Hi I've the following problem that makes me
a little bit mad with encoding a URL:


JRUN

URLEncoder.encode(downloads.jsp?group=%=group%);

--Method works on JRUN


TOMCAT 5.0

URLEncoder.encode(downloads.jsp?group=%=group%,iso-8859-1);

--at the bottom of the explorer it is displayed wrong
when I look at the properties of the HTML-Site
it is display correct.
The hyperlink is not found.
I also tested it with utf-8 and windows charsets but nothing helped.


Can someone help me?

Thanks a lot


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]