I have a CGI script which returns a 202 HTTP status code
(Accepted as per RFC 2616). When I first visit the page,
IE returns the page data just fine. But if I refresh the
page, IE sits and spins as if it is expecting more data
from the server. Is IE working correctly? What's the
expected behavior of a browser if it receives a 202 HTTP
status code?

"David Sisson" <(E-Mail Removed)> wrote in message
news:073501c3da4e$59d28920$(E-Mail Removed)...
> I have a CGI script which returns a 202 HTTP status code
> (Accepted as per RFC 2616). When I first visit the page,
> IE returns the page data just fine. But if I refresh the
> page, IE sits and spins as if it is expecting more data
> from the server. Is IE working correctly? What's the
> expected behavior of a browser if it receives a 202 HTTP
> status code?

It sounds like IE is responding correctly:
http://www.w3.org/Protocols/rfc2616/...html#sec10.2.3

> It sounds like IE is responding correctly:
> http://www.w3.org/Protocols/rfc2616/...html#sec10.2.3

How can it be correct? The first time it shows a result and the second time it doesn't show a result. Either it behaved correctly the first time and did not the second time or it is the other way around. Either way, IE had to behave incorrectly one of the times.

A good analogy would be if you didn't know how to spell something in a text document -- if you spell it both ways you guarantee that you're wrong 100% of the time.

Most people compare the behavior of the 202 status message to the well known 404 status message -- both return messages indicating that the sought for data was not available. I would say that the correct behavior here is that IE would treat the 202 in the same manner as it does 404 (which means bringing up a constructed 202 page informing the user that the requested data is not yet available).

"David Sisson" <(E-Mail Removed)> wrote in message
news:0936CEEF-6471-463D-BDAA-(E-Mail Removed)...
> > It sounds like IE is responding correctly:
> > http://www.w3.org/Protocols/rfc2616/...html#sec10.2.3
>
> How can it be correct? The first time it shows a result and the second
time it doesn't show a result.

The browser reports or renders what the server sends it. If it works one time
and not another, it sounds like there is a problem with the script or server.

Check the HTTP headers when it renders correctly and you'll know for sure.

Okay, so I tested the script I use to generate the 202 status code. It returns the same value every time and I additionally verified that Mozilla and Netscape (yes, same underlying engine) both handle the transaction from the server flawlessly. Note that when I change the error code from 202 to 200 that Internet Explorer does not exhibit the display/never come back issue, so it's highly unlikely that Internet Explorer is having an issue with the chunked encoding. I suspect the real issue comes back to the cache implementation in IE. Sample test data follows


bash$ telnet localhost 8
Trying ::1..
Trying 127.0.0.1..
Connected to localhost
Escape character is '^]'
GET /cgi-bin/vision/mmresult.pl HTTP/1.
Host: taxes.corp.yahoo.co

HTTP/1.1 202 Accepte
Date: Fri, 16 Jan 2004 01:20:52 GM
P3P: policyref="http://p3p.yahoo.com/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV
Connection: clos
Transfer-Encoding: chunke
Content-Type: text/xm

d
<?xml version="1.0" encoding="UTF-8"?><?xml-stylesheet type="text/xsl" href="http://taxes.corp.yahoo.com/vision/errormessage.xsl"?><ErrorMessage><Text>Please retry in 30 seconds.</Text></ErrorMessage