RE: Tomcat and the HttpServletRequest Object
Would anyone in the Project Management Committee, Advisory board, or the committer group acknowledge that this bug is understood and will be considered in the next releases of Tomcat? Thank you, Jeff Grangier Founder Chief Architect YourWebPro Inc. (847) 454-8000 -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Friday, August 12, 2005 7:48 PM To: Tomcat Users List Subject: Re: Tomcat and the HttpServletRequest Object From: Hassan Schroeder [EMAIL PROTECTED] :snips from: http://www.w3.org/TR/html401/interact/forms.html#h-17.13 So it seems the HTML specification *does* require the parts be sent in particular (source) order. Thanks! I was using the wrong search terms-- 'parameter' instead of 'control name' and so I never found that. At which point I assumed the specification was silent on the matter and I could do whatever I pleased. :) So I stand corrected on the browser behavior part. But it has nothing to say about what *processing agents* do with 'em. And if the servlet spec *doesn't* demand that the parts be stored and made available in that same order... Assuming enough people can be convinced that this is broken, there's where the fix needs to be applied. Until the Servlet specification says that the order of request parameters must be preserved, Tomcat is free to do whatever it wants with them. Greg Murray (the Servlet specification lead) has asked for input on what we'd all like to see in the next version, so here's a chance to comment: http://weblogs.java.net/blog/gmurray71/archive/2005/07/got_servlets.html You can also get involved with the JCP: http://www.jcp.org/en/home/index -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and the HttpServletRequest Object
Jeff Grangier wrote: Would anyone in the Project Management Committee, Advisory board, or the committer group acknowledge that this bug is understood and will be considered in the next releases of Tomcat? The issue is understood. This is not a bug, since there is no spec violation. Given the strength of your feelings, you should lobby the spec team for the change. That way, all servlet containers will implement this feature. I don't see any committer wanting to scratch this particular itch. You could implement it yourself and submit it as an enhancement request but, like any patch, one of the committers would need to apply it and any committer concerns leading to a binding -1 would also need to be addressed. I can't speak for the rest if the committers but at best I am going to be -0 on this and depending on the patch might be -1. It is obviously difficult to comment on a patch that doesn't yet exist but my key concerns at this point are: 1. It would encourage the development of non-portable applications 2. It adds unnecessary (not required by the spec) bloat 3. Making it configurable adds yet more code/complexity (but does address my first concern as long as the default is the current behaviour) For the record, and given previous comments on this thread, performance is a concern but it is quite a long way down my list. Again, speaking purely personally, I don't see this as something that needs to be addressed in any future release. If the spec mandates this change then I'll be first in line to implement it. Until that time there are enough things that need doing to keep me and the other committers busy at the moment. Other committers may well have differing views but that is my $0.02 Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and the HttpServletRequest Object
Jeff, You still haven't given a rationale why you *need* the parameters presented in a specific order (even though the brower's supposed to produce that result). I've worked with a set of generic form processing servlets and never had the desperate need to know the order upon receipt; if I'm manually inspecting/debugging a submission, I'm doing a SELECT...ORDER BY... from a database anyway. My suggestion, if you really, really, really need to know the order of appearance in the originating form (and you don't want to preface each input name with an indexing numeric value as suggested earlier): a.. write some (client-side) JScript to traverse the document's DOM (starting from the form node) just PRIOR TO SUBMISSION, b.. create a delimeted string of parameter names for each input node encountered c.. stuff that delimeted string value into a input type=hidden name=formInputOrder d.. form.submit(); On the TC/servlet side, a.. get the value of the formInputOrder parameter b.. pull all the names from the enumeration of param names provided by the request c.. sort that list based on a Comparator implementation that compares the relative positions of each comparee within the formInputOrder value (Note that it's always good to wrap both comparees with the delimeter used by the formInputOrder value.) This suggestion assumes a fairly distinct set of input names. If your form has multiple inputs with the same name (or a select that allows multiple options), then, obviously, the above has some weaknesses.
RE: Tomcat and the HttpServletRequest Object
I see nothing in the specification that specifies the order of the elements
returned in the enumeration.
Why do you think this is a bug?
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-Original Message-
From: Jeff Grangier [mailto:[EMAIL PROTECTED]
Sent: Friday, August 12, 2005 11:22 AM
To: tomcat-user@jakarta.apache.org
Subject: Tomcat and the HttpServletRequest Object
Hello,
I have migrated my application from iPlanet to Tomcat 5.5
(latest build as
of today) and getting weird results with the
HttpServletRequest object:
Each Element out the getParameterNames enumeration used to be
ordered based
on the html form layout posting the data (using iPLanet).
But, after the
migration the fields are coming in random order when I try to
loop through
the fields dynamically. . .
Here is a snapshot of the code:
Enumeration paramNames = req.getParameterNames();
while(paramNames.hasMoreElements())
{
paramName = (String)paramNames.nextElement();
.
.
.
Has anyone encountered this issue before? Is there a work around?
Thank you in advance for your help,
Jeff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat and the HttpServletRequest Object
Hello George,
I will consider it an ehancement if it is not in the specification. Adding a
logical order to the list makes it much easier to manage dynamically.
Otherwize, any programmer will have to create their own proprietary indexing
and ordering logic for it.
Let me know if I can help in this upgrade?
Thanks,
Jeff
-Original Message-
From: George Sexton [mailto:[EMAIL PROTECTED]
Sent: Friday, August 12, 2005 12:40 PM
To: 'Tomcat Users List'
Subject: RE: Tomcat and the HttpServletRequest Object
I see nothing in the specification that specifies the order of the elements
returned in the enumeration.
Why do you think this is a bug?
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-Original Message-
From: Jeff Grangier [mailto:[EMAIL PROTECTED]
Sent: Friday, August 12, 2005 11:22 AM
To: tomcat-user@jakarta.apache.org
Subject: Tomcat and the HttpServletRequest Object
Hello,
I have migrated my application from iPlanet to Tomcat 5.5
(latest build as
of today) and getting weird results with the
HttpServletRequest object:
Each Element out the getParameterNames enumeration used to be
ordered based
on the html form layout posting the data (using iPLanet).
But, after the
migration the fields are coming in random order when I try to
loop through
the fields dynamically. . .
Here is a snapshot of the code:
Enumeration paramNames = req.getParameterNames();
while(paramNames.hasMoreElements())
{
paramName = (String)paramNames.nextElement();
.
.
.
Has anyone encountered this issue before? Is there a work around?
Thank you in advance for your help,
Jeff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat and the HttpServletRequest Object
Even if I were to write this as an enhancement, I can tell you from past
experience it would be rejected out of hand by the committers.
In your particular case, the tool you were using before used something like
a Vector or ArrayList to hold the parameter name/value pairs. Tomcat is
almost certainly using a HashMap of some sort. Any deterministic
implementation is going to be slower than the current random access
implementation. Committers will savage any submission that appears slower
and the person submitting it. No thanks, I'm not going there.
Even if Tomcat were to work in the manner desired, there's nothing that says
that every browser is going to submit the form elements in their order of
definition. You really need to abandon this idea and make your application
more robust.
You remind me of people who do SQL database development. They don't specify
an ORDER BY clause on their statements, but it always came back in the order
they wanted. Then one day, they upgraded versions of the database or the
query optimizer decided to take a different path, and all of a sudden the
results are coming out of order. Much wailing and attempted reporting of
bugs ensues... The truth is in SQL, that if you don't specify an ORDER BY
clause, the database can return the results in any order it likes.
Taking advantage of an implementation specific behavior is natural, but it
can lead (as you have found out) to non-portable code. The final arbiter is
the specification, and if the specification doesn't describe the behavior,
you can't say anything about it.
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-Original Message-
From: Jeff Grangier [mailto:[EMAIL PROTECTED]
Sent: Friday, August 12, 2005 12:19 PM
To: 'Tomcat Users List'
Subject: RE: Tomcat and the HttpServletRequest Object
Hello George,
I will consider it an ehancement if it is not in the
specification. Adding a
logical order to the list makes it much easier to manage dynamically.
Otherwize, any programmer will have to create their own
proprietary indexing
and ordering logic for it.
Let me know if I can help in this upgrade?
Thanks,
Jeff
-Original Message-
From: George Sexton [mailto:[EMAIL PROTECTED]
Sent: Friday, August 12, 2005 12:40 PM
To: 'Tomcat Users List'
Subject: RE: Tomcat and the HttpServletRequest Object
I see nothing in the specification that specifies the order
of the elements
returned in the enumeration.
Why do you think this is a bug?
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-Original Message-
From: Jeff Grangier [mailto:[EMAIL PROTECTED]
Sent: Friday, August 12, 2005 11:22 AM
To: tomcat-user@jakarta.apache.org
Subject: Tomcat and the HttpServletRequest Object
Hello,
I have migrated my application from iPlanet to Tomcat 5.5
(latest build as
of today) and getting weird results with the
HttpServletRequest object:
Each Element out the getParameterNames enumeration used to be
ordered based
on the html form layout posting the data (using iPLanet).
But, after the
migration the fields are coming in random order when I try to
loop through
the fields dynamically. . .
Here is a snapshot of the code:
Enumeration paramNames = req.getParameterNames();
while(paramNames.hasMoreElements())
{
paramName = (String)paramNames.nextElement();
.
.
.
Has anyone encountered this issue before? Is there a work around?
Thank you in advance for your help,
Jeff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and the HttpServletRequest Object
From: Jeff Grangier [EMAIL PROTECTED] Each Element out the getParameterNames enumeration used to be ordered based on the html form layout posting the data (using iPLanet). But, after the migration the fields are coming in random order when I try to loop through the fields dynamically. . . AFAIK, there's nothing in the HTTP spec that says what order the browser must send the parameters in. Most browsers send them in the order they appear in the HTML source... but that's not guaranteed. And then there's nothing in the Servlet spec that says the container must keep them in the same order that the browser sent them. What are you doing that depends on the order of the request params? -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat and the HttpServletRequest Object
Hey Dude,
I was certainly not trying to be arbitrary . . . If Iplanet is more robust
in this area don't take it personally. As far as your sour memory in DB
development, please leave me out of it. This was a simple question that
makes a lot of sense when you are building any web applications. If there is
a problem with the specification, then it should be changed to accommodate
the user. Tomcat or any other software of that sort are loaded with
functions/features that sacrifice performance with functionality, this is
what you call an option.
Jeff Grangier
-Original Message-
From: George Sexton [mailto:[EMAIL PROTECTED]
Sent: Friday, August 12, 2005 1:46 PM
To: 'Tomcat Users List'
Subject: RE: Tomcat and the HttpServletRequest Object
Even if I were to write this as an enhancement, I can tell you from past
experience it would be rejected out of hand by the committers.
In your particular case, the tool you were using before used something like
a Vector or ArrayList to hold the parameter name/value pairs. Tomcat is
almost certainly using a HashMap of some sort. Any deterministic
implementation is going to be slower than the current random access
implementation. Committers will savage any submission that appears slower
and the person submitting it. No thanks, I'm not going there.
Even if Tomcat were to work in the manner desired, there's nothing that says
that every browser is going to submit the form elements in their order of
definition. You really need to abandon this idea and make your application
more robust.
You remind me of people who do SQL database development. They don't specify
an ORDER BY clause on their statements, but it always came back in the order
they wanted. Then one day, they upgraded versions of the database or the
query optimizer decided to take a different path, and all of a sudden the
results are coming out of order. Much wailing and attempted reporting of
bugs ensues... The truth is in SQL, that if you don't specify an ORDER BY
clause, the database can return the results in any order it likes.
Taking advantage of an implementation specific behavior is natural, but it
can lead (as you have found out) to non-portable code. The final arbiter is
the specification, and if the specification doesn't describe the behavior,
you can't say anything about it.
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-Original Message-
From: Jeff Grangier [mailto:[EMAIL PROTECTED]
Sent: Friday, August 12, 2005 12:19 PM
To: 'Tomcat Users List'
Subject: RE: Tomcat and the HttpServletRequest Object
Hello George,
I will consider it an ehancement if it is not in the
specification. Adding a
logical order to the list makes it much easier to manage dynamically.
Otherwize, any programmer will have to create their own
proprietary indexing
and ordering logic for it.
Let me know if I can help in this upgrade?
Thanks,
Jeff
-Original Message-
From: George Sexton [mailto:[EMAIL PROTECTED]
Sent: Friday, August 12, 2005 12:40 PM
To: 'Tomcat Users List'
Subject: RE: Tomcat and the HttpServletRequest Object
I see nothing in the specification that specifies the order
of the elements
returned in the enumeration.
Why do you think this is a bug?
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
-Original Message-
From: Jeff Grangier [mailto:[EMAIL PROTECTED]
Sent: Friday, August 12, 2005 11:22 AM
To: tomcat-user@jakarta.apache.org
Subject: Tomcat and the HttpServletRequest Object
Hello,
I have migrated my application from iPlanet to Tomcat 5.5
(latest build as
of today) and getting weird results with the
HttpServletRequest object:
Each Element out the getParameterNames enumeration used to be
ordered based
on the html form layout posting the data (using iPLanet).
But, after the
migration the fields are coming in random order when I try to
loop through
the fields dynamically. . .
Here is a snapshot of the code:
Enumeration paramNames = req.getParameterNames();
while(paramNames.hasMoreElements())
{
paramName = (String)paramNames.nextElement();
.
.
.
Has anyone encountered this issue before? Is there a work around?
Thank you in advance for your help,
Jeff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED
Re: Tomcat and the HttpServletRequest Object
I have the same bloody problem. The application is a generic form handler that
e-mails the form values. Most (all) of the clients expect the values to be in
the same order as the form itself.
I question the requirement to improve performance on request parameters. Vast
majority of the requests have less than 50 parameters and I fail to see how
changing a collection would improve performance. It might improve performance a
little bit when there's hundreds or thousands of parameters but not when it's
less than 50.
I noticed that SunOne 6.0 web server had the same problem when they embedded
Catalina in it. But they at least fixed the problem in subsequent releases (6.1
and above) when we complained about it. It makes you wonder - if Sun can fix
the problem even though performance requirements on SunOne servers are
significantly higher than tomcat because they are selling the product for
profit, why tomcat community would not do the same and make life easier for us
developers.
--
Bhupinder
On 12/08/2005 11:22 AM, Jeff Grangier wrote:
Hello,
I have migrated my application from iPlanet to Tomcat 5.5 (latest build as
of today) and getting weird results with the HttpServletRequest object:
Each Element out the getParameterNames enumeration used to be ordered based
on the html form layout posting the data (using iPLanet). But, after the
migration the fields are coming in random order when I try to loop through
the fields dynamically. . .
Here is a snapshot of the code:
Enumeration paramNames = req.getParameterNames();
while(paramNames.hasMoreElements())
{
paramName = (String)paramNames.nextElement();
.
.
.
Has anyone encountered this issue before? Is there a work around?
Thank you in advance for your help,
Jeff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat and the HttpServletRequest Object
The recognition (and so far, little acceptance) that form fields will not be sent in a guaranteed order by a browser, and never mind that, because even if your browser does, the container doesn't guarantee an order either... is from Beginner's Servlets. But maybe I only think that because the vast majority of my time in servlet/jsp development has not been spent with a container that has this nice enhancement. If you *output* the fields in a determined order, then it seems clear that you could also do something like name=%= index %_restOfName. Hackish, brutish and stupid as it might seem, to those that have not drunk the koolaid, I think it (or something like it) is a time-honoured tradition for most people that already understood this (the aforementioned koolaid drinkers). This is almost as good as realizing in late 2005 that referrer is not a reliable header. GAH. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and the HttpServletRequest Object
From: Bhupinder Dhillon [EMAIL PROTECTED] I have the same bloody problem. The application is a generic form handler that e-mails the form values. Most (all) of the clients expect the values to be in the same order as the form itself. You are depending on arbitrary browser behavior. As far as I can tell, there's nothing preventing me from writing a browser that, say, alphabetizes the request parameters before sending them to the server. Yes, most browsers send them in the order they appear in the HTML source, but unless/until some statement about request parameter order makes it into the relevant specification, you depend on that behavior at your own risk. This isn't something that can be handled by the container-- even if Tomcat stops rearranging the request params, you have no control over the browser implementation. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Tomcat and the HttpServletRequest Object
Hello Wendy, Is there anything we can do? I have worked with the MS DNA, .NET, SunOne, IBM Websphere frameworks and they all behave the same way by ordering the request parameters (first in first out). I know for sure that I am not the first one and neither the last one to have trouble with this kind of behavior using Tomcat. Even if the specification does not contain any direction on how to properly handle the request, Tomcat expected/ordered behavior would save hours of work to developers worldwide. I sure hope this issue is not an Open Source wake up call! Thanks for all your help, Jeff -Original Message- From: Wendy Smoak [mailto:[EMAIL PROTECTED] Sent: Friday, August 12, 2005 4:07 PM To: Tomcat Users List Subject: Re: Tomcat and the HttpServletRequest Object From: Bhupinder Dhillon [EMAIL PROTECTED] I have the same bloody problem. The application is a generic form handler that e-mails the form values. Most (all) of the clients expect the values to be in the same order as the form itself. You are depending on arbitrary browser behavior. As far as I can tell, there's nothing preventing me from writing a browser that, say, alphabetizes the request parameters before sending them to the server. Yes, most browsers send them in the order they appear in the HTML source, but unless/until some statement about request parameter order makes it into the relevant specification, you depend on that behavior at your own risk. This isn't something that can be handled by the container-- even if Tomcat stops rearranging the request params, you have no control over the browser implementation. -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and the HttpServletRequest Object
Wendy Smoak wrote: You are depending on arbitrary browser behavior. As far as I can tell, there's nothing preventing me from writing a browser that, say, alphabetizes the request parameters before sending them to the server. well. :snips from: http://www.w3.org/TR/html401/interact/forms.html#h-17.13 application/x-www-form-urlencoded ... 2. The control names/values are listed in the order they appear in the document. ... multipart/form-data ... A multipart/form-data message contains a series of parts, each representing a successful control. The parts are sent to the processing agent in the same order the corresponding controls appear in the document stream. ... So it seems the HTML specification *does* require the parts be sent in particular (source) order. But it has nothing to say about what *processing agents* do with 'em. And if the servlet spec *doesn't* demand that the parts be stored and made available in that same order... It's never even occurred to me to expect form variables in any order, though. For one thing, only successful controls are sent at all, so what arrives is intrinsically somewhat arbitrary, eh? :-) As always, YMMV! -- Hassan Schroeder - [EMAIL PROTECTED] Webtuitive Design === (+1) 408-938-0567 === http://webtuitive.com dream. code. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tomcat and the HttpServletRequest Object
From: Hassan Schroeder [EMAIL PROTECTED] :snips from: http://www.w3.org/TR/html401/interact/forms.html#h-17.13 So it seems the HTML specification *does* require the parts be sent in particular (source) order. Thanks! I was using the wrong search terms-- 'parameter' instead of 'control name' and so I never found that. At which point I assumed the specification was silent on the matter and I could do whatever I pleased. :) So I stand corrected on the browser behavior part. But it has nothing to say about what *processing agents* do with 'em. And if the servlet spec *doesn't* demand that the parts be stored and made available in that same order... Assuming enough people can be convinced that this is broken, there's where the fix needs to be applied. Until the Servlet specification says that the order of request parameters must be preserved, Tomcat is free to do whatever it wants with them. Greg Murray (the Servlet specification lead) has asked for input on what we'd all like to see in the next version, so here's a chance to comment: http://weblogs.java.net/blog/gmurray71/archive/2005/07/got_servlets.html You can also get involved with the JCP: http://www.jcp.org/en/home/index -- Wendy Smoak - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
