RE: Meta Refresh and jsessionid - a proposal
That works perfectly! I feel like a monkey for not trying that. Sorry to bother you guys. --- Ignacio J. Ortega [EMAIL PROTECTED] wrote: Why not simply encoding the url ? See http://nagoya.betaversion.org/bugzilla/show_bug.cgi?id=1482 Saludos , Ignacio J. Ortega -Mensaje original- De: craigmcc@localhost [mailto:craigmcc@localhost]En nombre de Craig R. McClanahan Enviado el: viernes 2 de noviembre de 2001 22:59 Para: Robert Lucier Cc: [EMAIL PROTECTED] Asunto: Re: Meta Refresh and jsessionid - a proposal On Fri, 2 Nov 2001, Robert Lucier wrote: Date: Fri, 2 Nov 2001 13:44:20 -0800 (PST) From: Robert Lucier [EMAIL PROTECTED] To: Craig R. McClanahan [EMAIL PROTECTED] Subject: Re: Meta Refresh and jsessionid - a proposal I understand, and that bothers me. Has there been any talk of modifying that portion of the spec to be compatible with the meta-refresh tag? The problem shows up on this and other lists fairly frequently. I don't recall any such discussion -- the best way to make sure it at least gets paid attention to is to submit feedback to the Servlet Spec feedback address ([EMAIL PROTECTED]). It may also be that the expert group doesn't consider compatible with the meta-refresh tag to be a very compelling argument: - Refresh is not a standard HTTP header - Browsers that misinterpret this kind of thing: meta http-equiv=refresh content=2;URL=http://foo/bar;jsessionid=12345; sound like they are broken in the first place -- they should be parsing on the first semicolon, not the second one. Craig --- Craig R. McClanahan [EMAIL PROTECTED] wrote: The servlet spec is pretty clear about where the session id is supposed to be. I don't think it is a good idea to introduce something that violates those requirements (and which would trap unwary developers into dependence on a non-standard implementation of this functionality). Craig On Fri, 2 Nov 2001, Robert Lucier wrote: Date: Fri, 2 Nov 2001 13:22:58 -0800 (PST) From: Robert Lucier [EMAIL PROTECTED] Reply-To: Tomcat Developers List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Meta Refresh and jsessionid - a proposal I'm having a seemingly common problem where I can't use url-rewriting with the META HTTP-EQUIV=Refresh tag because the semi-colon in the rewritten URL is confused with the delimiter in the meta tag. I didn't see a solution or workaround, so here's mine. I'd like to modify the HttpProcessor.parseRequest method to look for jsessionid= in the query string if ;jsessionid is not found in the uri. That way the existing encodeURL method will still work, but those who need the refresh method can put the jsessionid in the query string parameters. Please let me know if this is acceptable or if there is a better way to solve this problem __ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] __ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Meta Refresh and jsessionid - a proposal
I'm having a seemingly common problem where I can't use url-rewriting with the META HTTP-EQUIV=Refresh tag because the semi-colon in the rewritten URL is confused with the delimiter in the meta tag. I didn't see a solution or workaround, so here's mine. I'd like to modify the HttpProcessor.parseRequest method to look for jsessionid= in the query string if ;jsessionid is not found in the uri. That way the existing encodeURL method will still work, but those who need the refresh method can put the jsessionid in the query string parameters. Please let me know if this is acceptable or if there is a better way to solve this problem __ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Bug/Fix for HttpUtils.parseQueryString - IMPORTANT!
Thanks to George C. Hawkins for clearing up the specification and to Pier Fumagalli for correcting the spelling of my last name. It is now clear that interpreting b= as I suggested earlier would be wrong. But interpreting b=null might not be. Section 8.2.1 of RFC 1866, describing the form-urlencoded Media Type, says that The fields are listed in the order they appear in the document with the name separated from the value by '=' and the pairs separated from each other by ''. Fields with null values *may* be ommitted. (Emphasis mine) This seems to suggest that a null value may be sent, and the only way to differentiate a null value from an empty string would be to omit the '=' sign -- if there is no value, then adding separating the name from value with an equal sign makes no sense. Under this interpretation, the contents of the hashtable would not change, and no developer's previous assumption need change. Further, it would allow for a seemingly valid interpretation of the spec for the application/x-www-form-urlencoded mime type. Regards, Rob --- Craig R. McClanahan [EMAIL PROTECTED] wrote: On Mon, 3 Sep 2001, George C. Hawkins wrote: Date: Mon, 3 Sep 2001 16:52:32 +0100 From: George C. Hawkins [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED], George C. Hawkins [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: RE: Bug/Fix for HttpUtils.parseQueryString - IMPORTANT! I do not believe Mr. Lucifer's patch should be applied. As has been pointed out a number of times Tomcat is the reference implementation for the JSP and servlet JCRs. In the Servlet 2.3 PFD2 specification you find the following in the definition of parseQueryString(): The query string should be in the form of a string packaged by the GET or POST method, that is, it should have key-value pairs in the form key=value, with each pair separated from the next by a character. People regularly ask for features that run contrary to the specification (e.g. a common request/confusion is that parsePostData() should handle the multipart/form-data encoding) - these requests are turned down. If you want to change/query the specification talk to the JCR people not to the Tomcat implementers! As a practical matter, the suggested change would indeed violate the spec, and therefore should not be applied unless the spec were to be changed. In addition, it should be noted that the entire HttpUtils class has been deprecated in Servlet 2.3, because its methods are hopelessly inadqueate for dealing with requests that are not in the server's default character encoding. Therefore, it is pretty unlikely that suggested changes to this class will be incorporated into future versions of the spec. Once you migrate to a 2.3-based container, you can call ServletRequest.getParameterMap() to get a (read-only) Map of all the request parameters for this request (from both the query string and the body of POST requests), suitably converted into Unicode for you. If you want to process the query string in some different fashion, you can call HttpServletRequest.getQueryString() and parse it yourself. Craig McClanahan __ Do You Yahoo!? Get email alerts NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
Re: Bug/Fix for HttpUtils.parseQueryString
Was this information sufficient? I would be happy to make a patch to the latest source, or better explain my rationale for the fix. --- Robert Lucier [EMAIL PROTECTED] wrote: My apologies. That was against the jarkarta-servletapi-3.2.3 source. The file is javax.servlet.http.HttpUtils.java. --- Pier Fumagalli [EMAIL PROTECTED] wrote: Robert Lucier [EMAIL PROTECTED] wrote: Attatched is a fix for HttpUtils.parseQueryString(String s) which allows a key-only key value pair like b in a=1bc=2. This is necessary to work with some clients, and should not break anything else. It interprets the above as b=, instead of throwing an IllegalArgumentException like the original. It would be cool to know against what file/version it has been made... Pier __ Do You Yahoo!? Get email alerts NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com __ Do You Yahoo!? Get email alerts NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
RE: Bug/Fix for HttpUtils.parseQueryString
Thanks for the advice. Attached is the patch against the latest CVS source. --- Ignacio J. Ortega [EMAIL PROTECTED] wrote: Hola Robert: Please follow the guidelines http://jakarta.apache.org/site/source.html when submitting patches.. Thanks for the feedback.. Saludos , Ignacio J. Ortega -Mensaje original- De: Robert Lucier [mailto:[EMAIL PROTECTED]] Enviado el: sábado 1 de septiembre de 2001 0:36 Para: [EMAIL PROTECTED] Asunto: Bug/Fix for HttpUtils.parseQueryString Attatched is a fix for HttpUtils.parseQueryString(String s) which allows a key-only key value pair like b in a=1bc=2. This is necessary to work with some clients, and should not break anything else. It interprets the above as b=, instead of throwing an IllegalArgumentException like the original. __ Do You Yahoo!? Get email alerts NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com __ Do You Yahoo!? Get email alerts NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com HttpUtils.equalsignfix.diff
Re: Bug/Fix for HttpUtils.parseQueryString
My apologies. That was against the jarkarta-servletapi-3.2.3 source. The file is javax.servlet.http.HttpUtils.java. --- Pier Fumagalli [EMAIL PROTECTED] wrote: Robert Lucier [EMAIL PROTECTED] wrote: Attatched is a fix for HttpUtils.parseQueryString(String s) which allows a key-only key value pair like b in a=1bc=2. This is necessary to work with some clients, and should not break anything else. It interprets the above as b=, instead of throwing an IllegalArgumentException like the original. It would be cool to know against what file/version it has been made... Pier __ Do You Yahoo!? Get email alerts NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com
making HttpUtils of poor post args
This is a suggestion for a slight modification in the jakarta implementation of javax.servlet.http.HttpUtils. If this is the wrong forum for that I apologize. I'm using tomcat with a client app which has a sloppy form-urlencode. It will product a POST body like a=1bc=2 - with no equal sign after the b. Currently, this causes HttpUtils.parseQueryString to throw an IllegalArgumentException. While this is technically correct, it does prevent the use of Tomcat with that client. My first choice would be to interpret a=1bc=2 as meaning that b=. It seems like a fairly unambiguous interpretation. The attached diff makes that change. Regards, Rob Lucier __ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ HttpUtils.no_equal_sign_fix.diff
