On 4/27/2017 4:52 PM, Christopher Schultz wrote:
When I take your browser-encoded query string from above and send it
to Tomcat, I don't get any errors or anything.
Are you sure this isn't a problem with the application?
Hi Chris,
That happens to me too, in the sense that usually Tomcat throw
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Steve,
(Bringing this back into the list)
On 4/27/17 1:49 PM, Stephen Crawford wrote:
> Hi Chris,
>
> On 4/27/2017 12:47 PM, Christopher Schultz wrote:
>> Steve,
>>
>> On 4/27/17 12:23 PM, Stephen Crawford wrote:
>>> Hello All,
>>>
>>> We are ru
On 4/27/2017 2:27 PM, Mark Thomas wrote:
On 27/04/17 17:23, Stephen Crawford wrote:
Hello All,
We are running Tomcat 8.5.13 on Linux, mostly as a container for
Geoserver. We have a few apps (in Flash!) that have been running fine
untouched for at least six years but stopped working a few weeks
On 27/04/17 17:23, Stephen Crawford wrote:
> Hello All,
>
> We are running Tomcat 8.5.13 on Linux, mostly as a container for
> Geoserver. We have a few apps (in Flash!) that have been running fine
> untouched for at least six years but stopped working a few weeks ago. I
> believe the issue appear
Hello All,
We are running Tomcat 8.5.13 on Linux, mostly as a container for
Geoserver. We have a few apps (in Flash!) that have been running fine
untouched for at least six years but stopped working a few weeks ago. I
believe the issue appeared before we upgraded from Tomcat 6.0.24,
probably
at is being done in the above example
> appropriate?
No, ';' is a legitimate character in a URL, so by encoding it the proxy is
changing the name of the resource being asked for.
> 2. Shouldn't Tomcat be URL-decoding this and turning it into its original
> form?
>
No,
//foo/Example.action%3Bjsessionid%
3D196273839CE41F0BFBA445F63D3880EB
I do not have any control over the proxy that is doing this re-encoding.
I have two questions:
1. Is the URL encoding that is being done in the above example
appropriate?
2. Shouldn't Tomcat be URL-decoding this and turning it into its
original f
Shankar, Chris,
With reference to your previous posts
(From section 3.7.1 of the HTTP/1.1 spec).
I tried a small example by not forcing the request's content type,
and was able to see the Big5 characters without any problems even
when the Request's characterEncoding was null. The code bel
Christopher Schultz wrote:
Shouldn't you use the content-type of the request instead of just
forcing your own content-type? If the browser does not send a MIME type
with the request, then the default is defined to be ISO-8859-1:
Well, for a form post, that just means that the text of the body
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rashmi,
Rashmi Rubdi wrote:
> On 6/5/07, Shankar Unni <[EMAIL PROTECTED]> wrote:
>> (the page was already set to character
>> encoding Big5), the encoded value sent in the URL was rather screwy:
>>
>> The original character is (Big5) 0xAE 0x78.
>>
>>
ode(s, "Big5") doesn't like the above encoding:
it insists that both characters be encoded, or neither - it ends up
decoding this into "?x".
However, Tomcat actually returns the correct single chinese character
from "request.getParameter("userid")".
Is i
rom "request.getParameter("userid")".
>
> Is it doing the URL decoding in a different way than Java's built-in URL
> decoder?
Yes, it's using either UTF-8 or ISO-8859-1 to decode the URL parameters
(you can set this in your Connector's configuration) ins
t;. (!!)
Now Java's URLDecoder.decode(s, "Big5") doesn't like the above encoding:
it insists that both characters be encoded, or neither - it ends up
decoding this into "?x".
However, Tomcat actually returns the correct single chinese character
from "request.
13 matches
Mail list logo
