Mantis Bugtracker
  

Viewing Issue Advanced Details Jump to Notes ] View Simple ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000143 [Resin] minor always 05-06-05 00:00 11-30-05 14:43
Reporter ferg View Status public  
Assigned To
Priority high Resolution fixed Platform
Status closed   OS
Projection none   OS Version
ETA none Fixed in Version 3.0.15 Product Version 2.1.x
  Product Build 2.1.x
Summary 0000143: https returned periodically
Description RSN-137
(rep by David Rice)

This bug is causing production downtime.

    Resin is returning an HTTPS url from request.getRequestURL() even though the page is accessed through HTTP. This behavior is not consistent, but we have seen it on a couple of different apps at different times. Restarting Resin fixes the problem for a short while, but sometimes the problem will come back immediately and sometimes it will take several hours. Basically, we are determining the <base href="" /> to add to dynamic pages by calling the following code:
public static URL getBasePath(HttpServletRequest request) throws ServletException {
        try {
            URL urlFull = new URL(request.getRequestURL().toString()); // full URL of the action being called
            URL urlContext = new URL(urlFull, request.getContextPath() + "/"); // just the context path only (as a path)
            return urlContext;
        } catch (MalformedURLException e) {
            throw new ServletException(e);
        }
    }

We are using mod_caucho 2.1.14 in apache 2.0.54 on linux against Resin 3.0.12pro. The cluster is configured as follows:
                                                                                                                           
  <cluster>
    <srun id='milo' protocol='srun' index='1' host='milo.foo.com' port='6812' />
  </cluster>
                                                                                                                           
I don't believe the problem is coming from the mod_caucho side of things because we did a tcpdump (attachments) of the srun connection and it said the request was not HTTPS. I have included the tcpdumps and a printout of the packet structure that I wrote based on the parsing logic in RunnerRequest. (The .dat files are the raw payload of the tcp packets, the .out files are the parsed versions)

Packet 1: This request came in via HTTP, but the above code returned HTTPS.
Packet 3: This request came in via HTTP and appropriately returned HTTP.
Packet 4: This request came in via HTTPS and appropriately returned HTTPS.

I am stuck at this point in how to further debug the problem.
Steps To Reproduce
Additional Information
Attached Files

- Relationships

- Notes
(0000172)
ferg
05-06-05 00:00

The code looks fine. The Request.isSecure field is properly initialized to false at the beginning of each request.

If you can turn on full logging and reproduce the error, it will help see if mod_caucho is properly sending the secure property.

<log id="" href="log/debug.log"/>

 
(0000173)
ferg
05-06-05 00:00

The issue is on the RunnerRequest side, not mod_caucho.
 

- Issue History
Date Modified Username Field Change
05-06-05 00:00 ferg New Issue
11-30-05 00:00 administrator Fixed in Version  => 3.0.15
11-30-05 14:43 ferg Status resolved => closed


Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
29 total queries executed.
27 unique queries executed.
Powered by Mantis Bugtracker