| Re: totally WEIRD bug? Firefox caching? [message #185380 is a reply to message #185372] |
Fri, 21 March 2014 07:33   |
Arno Welzel
Messages: 317
Registered: October 2011
Karma:
|
Senior Member |
|
|
The Natural Philosopher, 2014-03-20 19:39:
> On 20/03/14 14:53, Arno Welzel wrote:
>> Am 20.03.2014 12:26, schrieb The Natural Philosopher:
>>
>>> On 20/03/14 09:13, Arno Welzel wrote:
>>>> Am 19.03.2014 18:25, schrieb The Natural Philosopher:
>>>>
>>>> > I have TWO IDENTICAL PHP FILES.
>>>> >
>>>> > They are supposed to display an image got from a database.
>>>> >
>>>> > One does. The other does not.
>>>> >
>>>> > It persistently tells me the image is corrupted.
>>>> >
>>>> > I have even copied one file that works directly over the other. It still
>>>> > doesn't work.
>> [...]
>>> What is happning - and oddly running it against a test version of IE6 in
>>> my XP VM showed it up, was that it was outputting a '404 file not found'
>>> text BEFORE outputting perfectly valid PNG.
>>>
>>> Why this is happening is a bug somewhere else completely.
>>>
>>> IE 6 simply showed the text and the binary gobbledygook which was the
>>> clue I needed.
>>
>> Yes, because IE 6 assumes the user may not understand a server generated
>> error message and shows its own message as long as the reponse is below
>> a certain size limit (AFAIR less than 4000 bytes, but i may not remember
>> correctly). This is even more annoying - sometimes you see the message
>> from IE itself and sometimes
>>
>>> How this has happened will take me some time to understand because the
>>> line that says '404 not found' is followed - or I thought it was - by
>>> an exit(); statement.
>>>
>>>> Either Firefox once got an invalid image and cached the response or the
>>>> server does not respond the way you think. Maybe a BOM in the PHP file?
>>>> This may not be visible in your editor, but it can cause all sort of
>>>> problems.
>>>>
>>>>
>>> Firefox makes it hard to debug because it DOES cache bad results: I
>>> usually fix that by sending random nonsensical GET parameters which are
>>> ignored to ensure it thinks its a different URL each time.
>>>
>>> It a huge minus against firefox that it didn't - even using the
>>> debugging console - show me what was really going on, whereas IE6 did.
>>
>> You should learn to read HTTP response headers in the developer console
>> of Firefox. When I open <http://arnowelzel.de/wiki/en/tools/rwinfo>
>> there the developer console of Firefox tells me EXACTLY what is going on:
>>
>> 1) The server responded with a status code 404 (not found)
>>
>
> The problem is that it didn't send an error code in the header
> It sent a valid header, the some error text, and then the PNG
In this case you can't blame Firefox - Firefox behaved correctly. It got
a response but WITHOUT status 404. So it cached the response and
displayed the result. Even though the result was not a valid image -
it's not the fault of Firefox when the server sends garbish and declares
that garbish to be a PNG image without any hint that something went
wrong (HTTP status 4xx or 5xx etc.).
On the other hand it looks like IE6 handled the response from the server
as HTML even though a MIME header was present that clearly states the
content is an image.
Well - in that particular case it may helped to find the problem. But
technically IE6 is broken anyway. I assume IE6 did not see a ".png" etc.
in the URL and since the response contained some text which *may* be
HTML (or text) it decided to treat the content as HTML (or text) and
just ignore the MIME-Type in the header.
And finally - neither Firefox nor IE6 are debugging tools - they are
browsers. But Firefox still offers many helpful tools to find errors,
where IE6 doesn't.
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]