Mailing-List: contact users-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@httpd.apache.org
Message-ID: <4113959F.7010905@fusebox.com>
Date: Fri, 06 Aug 2004 16:28:47 +0200
From: basem moussa <bmoussa@fusebox.com>
User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626)
MIME-Version: 1.0
To: users@httpd.apache.org
References: <1091672139.87337.ezmlm@httpd.apache.org>
 <p0600202abd37ec4b3641@[138.110.10.65]>
In-Reply-To: <p0600202abd37ec4b3641@[138.110.10.65]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [users@httpd] Re: MSIE noncompliance in a mod_rewritten SSL
 environment

Dan Wilga wrote:

>> From: basem moussa <bmoussa@fusebox.com>
>>
>> EVIDENCE:  The following is abbreviated log output concerning one of the
>> affected images.  Notice the difference in HTTP codes.  Both start out
>> the same but upon redirection, my Firefox browsing comes up with success
>> while MSIE comes up with the 304 "Not Modified" conditional, and pukes
>> on it only about 15% of the time.  The images do not appear broken, but
>> rather have a little red X in their stead:
>>
>> "GET /imgs/topnav_logo.gif HTTP/1.1" 302 318
>> "https://zoostage.fusebox.com/fcart/index.php?id=7_1_2_1" "Mozilla/5.0
>> (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.8"
>> "GET /imgs/topnav_logo.gif HTTP/1.1" 200 4472 "-" "Mozilla/5.0 (Windows;
>> U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.8"
>>
>> "GET /imgs/topnav_logo.gif HTTP/1.1" 302 318
>> "https://zoostage.fusebox.com/fcart/index.php?id=7_1_2_1" "Mozilla/4.0
>> (compatible; MSIE 6.0; Windows NT 5.1)"
>> "GET /imgs/topnav_logo.gif HTTP/1.1" 304 -
>> "https://zoostage.fusebox.com/fcart/index.php?id=7_1_2_1" "Mozilla/4.0
>> (compatible; MSIE 6.0; Windows NT 5.1)"
>
>
> A return of 304 in this is should be the result of the client (IE) 
> having sent an "If-Modified-Since" header in the request. Assuming 
> this is the case, it makes perfect sense that Apache would return a 
> 304, since I doubt that your GIF image has changed.
>
> Now, as to why this would cause IE to display a broken image, I do 
> have a couple of possibilities:
>
> - Is the page a mixture of secure (https:) and insecure (http:) code 
> and images? Or does it use frames that are a mixture?


Yes, it is a mixture.  Both http and https share the exact same 
docroot.  Rewrite rules for both http and https servers simply redirect 
requests so that anything ^fcart/ is handled by the https server while 
everything else is handled by http.  So you click on a link to a page 
whose URI ^fcart/ and are redirected to https.  once there, requests for 
elements in that page which do not ^fcart/ get redirected back to the 
http server.


> - Or, does the page itself have non-cache headers that get sent with 
> it, like "Expires:" or "Pragma: no-cache"? If so, then perhaps IE is 
> expiring the images from its cache, but not entirely. I seem to recall 
> a case where it would act as though the image had been removed from 
> cache, but still send an "If-Modified-Since" header.


As a matter of fact, I just found this in headers under /fcart:
header("Expires: 0");
header("Pragma: no-cache");
header("Cache-control: No-Cache");

If this is the case, I would expect all browsers to not make the 
conditional GET you speak of, like Firefox.


>
> What happens if you manually type-in the full URL of just the image? 
> Does it load?


every time.  This discussion has already given me more to dig through.  
Thanks a lot for the help, Dan.

basem

---------------------------------------------------------------------
The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:http://httpd.apache.org/userslist.html> for more info.
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
   "   from the digest: users-digest-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org