You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by ma...@apache.org on 2005/01/15 21:27:06 UTC

cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java

markt       2005/01/15 12:27:05

  Modified:    catalina/src/share/org/apache/catalina/core
                        ApplicationHttpRequest.java
  Log:
  Fix bug 28222. request.getRequestURL() in forwarded jsp/servlet returns
    original url rather than new url as per SRV8.4. Uses same code as
    CoyoteRequest.getRequestURL()
  
  Revision  Changes    Path
  1.15      +28 -1     jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java
  
  Index: ApplicationHttpRequest.java
  ===================================================================
  RCS file: /home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core/ApplicationHttpRequest.java,v
  retrieving revision 1.14
  retrieving revision 1.15
  diff -u -r1.14 -r1.15
  --- ApplicationHttpRequest.java	22 Dec 2004 23:12:50 -0000	1.14
  +++ ApplicationHttpRequest.java	15 Jan 2005 20:27:05 -0000	1.15
  @@ -325,6 +325,33 @@
   
   
       /**
  +     * Override the <code>getRequestURL()</code> method of the wrapped
  +     * request.
  +     */
  +    public StringBuffer getRequestURL() {
  +
  +        StringBuffer url = new StringBuffer();
  +        String scheme = getScheme();
  +        int port = getServerPort();
  +        if (port < 0)
  +            port = 80; // Work around java.net.URL bug
  +
  +        url.append(scheme);
  +        url.append("://");
  +        url.append(getServerName());
  +        if ((scheme.equals("http") && (port != 80))
  +            || (scheme.equals("https") && (port != 443))) {
  +            url.append(':');
  +            url.append(port);
  +        }
  +        url.append(getRequestURI());
  +
  +        return (url);
  +
  +    }
  +
  +
  +    /**
        * Override the <code>getServletPath()</code> method of the wrapped
        * request.
        */
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java

Posted by Remy Maucherat <re...@apache.org>.
Mark Thomas wrote:
> On re-reading the spec it is less clear than I first thought. Personally 
> I favour leaving the patch as is but would be happy to revert it pending 
> clarification from the spec team.

I'm ok with leaving the patch, as there's nothing which allows saying 
which behavior is the right one.

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java

Posted by Mark Thomas <ma...@apache.org>.
Bill Barker wrote:
> From: "Remy Maucherat" <re...@apache.org>
>>markt@apache.org wrote:
>>>markt       2005/01/15 12:27:05
>>>
>>>  Modified:    catalina/src/share/org/apache/catalina/core
>>>                        ApplicationHttpRequest.java
>>>  Log:
>>>  Fix bug 28222. request.getRequestURL() in forwarded jsp/servlet returns
>>>    original url rather than new url as per SRV8.4. Uses same code as
>>>    CoyoteRequest.getRequestURL()
>>
>>I think the bug report may actually be invalid, because:
>>- getRequestURL is not a path element
>>- the javadoc associated with the method is:
>>Reconstructs the URL the client used to make the request. The returned
>>URL contains a protocol, server name, port number, and server path, but
>>it does not include query string parameters.
>>
>>I don't know for sure, however. Any comments on that ?
> 
> I'd tend to go with Remy's interpretation, but it is a grey area in the
> spec.  The javadocs for HttpServletRequest.getRequestURI (which is a path
> element) say to use the deprecated HttpUtils.getRequestURL to construct a
> URL, which suggests that HttpUtils.getRequestURL should use the path
> elements.  However the javadocs for HttpUtils.getRequestURL are pretty much
> the same as for HttpServletRequest.getRequestURL, making the picture a bit
> grey.
> 

On re-reading the spec it is less clear than I first thought. Personally 
I favour leaving the patch as is but would be happy to revert it pending 
clarification from the spec team.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java

Posted by Bill Barker <wb...@wilshire.com>.
----- Original Message -----
From: "Remy Maucherat" <re...@apache.org>
To: "Tomcat Developers List" <to...@jakarta.apache.org>
Sent: Thursday, February 24, 2005 9:04 AM
Subject: Re: cvs commit:
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core
ApplicationHttpRequest.java


>markt@apache.org wrote:
>> markt       2005/01/15 12:27:05
>>
>>   Modified:    catalina/src/share/org/apache/catalina/core
>>                         ApplicationHttpRequest.java
>>   Log:
>>   Fix bug 28222. request.getRequestURL() in forwarded jsp/servlet returns
>>     original url rather than new url as per SRV8.4. Uses same code as
>>     CoyoteRequest.getRequestURL()
>
>I think the bug report may actually be invalid, because:
>- getRequestURL is not a path element
>- the javadoc associated with the method is:
>Reconstructs the URL the client used to make the request. The returned
>URL contains a protocol, server name, port number, and server path, but
>it does not include query string parameters.
>
>
>I don't know for sure, however. Any comments on that ?
>

I'd tend to go with Remy's interpretation, but it is a grey area in the
spec.  The javadocs for HttpServletRequest.getRequestURI (which is a path
element) say to use the deprecated HttpUtils.getRequestURL to construct a
URL, which suggests that HttpUtils.getRequestURL should use the path
elements.  However the javadocs for HttpUtils.getRequestURL are pretty much
the same as for HttpServletRequest.getRequestURL, making the picture a bit
grey.

>Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org





This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.

In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.



Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/core ApplicationHttpRequest.java

Posted by Remy Maucherat <re...@apache.org>.
markt@apache.org wrote:
> markt       2005/01/15 12:27:05
> 
>   Modified:    catalina/src/share/org/apache/catalina/core
>                         ApplicationHttpRequest.java
>   Log:
>   Fix bug 28222. request.getRequestURL() in forwarded jsp/servlet returns
>     original url rather than new url as per SRV8.4. Uses same code as
>     CoyoteRequest.getRequestURL()

I think the bug report may actually be invalid, because:
- getRequestURL is not a path element
- the javadoc associated with the method is:
Reconstructs the URL the client used to make the request. The returned 
URL contains a protocol, server name, port number, and server path, but 
it does not include query string parameters.

I don't know for sure, however. Any comments on that ?

Rémy

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org