Remy Maucherat wrote:

Jess Holle wrote:

Remy Maucherat wrote:

For example:
remm        2003/12/10 14:26:28

Modified: catalina/src/share/org/apache/coyote/tomcat5
CoyoteConnector.java CoyoteRequest.java
mbeans-descriptors.xml
Log:
- Add a flag to allow using the encoding specified in the contentType for
the URI paramters. This is disabled by default, not compliant with the standards,
but present for compatibility.

But as per my previous message I /cannot /change this on a connector basis. I /must /make this determination on a per-request basis -- /and the servlet spec specifically allows me to do this via the setCharacterEncoding() API as I read it/.

The content-type header and your setCharacterEncoding call both control the request entity body character encoding. So if using the entity body encoding *also* for URI parameters, what would you think it would do ?

This is a good question -- but one which only applies to POST. My bug case was explictly with GET.


If there is an entity body encoding specified in the request, then I am not sure which should override. If there is not, then I would presume setCharacterEncoding() should win out. If the only issue is when these differ, then I believe that site designers should simply ensure they don't.

There's a query page in BZ, also, and as I said, many threads on tomcat-dev (use the archives).

I queried both at some length -- especially BZ. I'll query the tomcat-dev archives further, but again a simple synopsis of how Tomcat's behavior satisfies the spec and is thus not a bug attached to the bug would save everyone a lot of trouble in cases like this. In other words, where a bug that from all indications appears to be a spec violation is closed as "INVALID" an explanation attached to the bug itself would be a *very* good idea.

Sorry, I'm not a broken record, and I will not go on repeating the same stuff over and over 20 times.

Just once on the one of the bug reports in the duplicate chain would suffice. [At least in my handling of our internal bug system it is common place to copy/paste the final status from e-mail threads and/or lists into the bugs attachments when closing the bug.]


--
Jess Holle



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



Reply via email to