Re: Help requested for reload error

[zimpel@t-online.de (Holger Zimmermann)]

VALETTE Eric schrieb:
> 
> I have sucessfully ported Pi3 to the ChorusOS RTOS.
> It mainly works and I can display HTML document.
> But I still have a problem with the netscape
> "reload" button. Each time I get an error
> "document contained no data".
> 
> I have traced the execution path and found the following :
> 
> ConditionalGet::Handle returns an error because the file
> did not change as chown by the code fragment below :
> 
>                 /* ---
>                 OK, no modification, issue an internal redirect with status 304
>                 --- */
>                 return HTTPUtil_doHTTPError( &tPIHTTP, ST_NOTMODIFIED );
> 
> The result is that in
> 
> int HTTPCore_dispatch()
> {
> 
> iRet = Internal_ExecutePhase( pPIHTTP, pSG->lHandlers );
> 
> }
> 
> iRet is returned with INT_REDIRECT as the return value.
> as iPhase = 7, I restart the code several time ..
> 
> case INT_REDIRECT:
>                                 if ( iPhase<=PH_HANDLE && iNumRedirects<=MAX_REDIRECTS )
>                                         {
>                                         iStartPhase = PH_MAPPING;
>                                         iNumRedirects++;
>                                         goto again;
>                                         };
>                                 return PIAPI_ERROR
> 
> Up to when iNumRedirects = MAX_REDIRECTS and then I return an error.
> wich finish by calling ::shutdown to the socket and lead to
> the message.
> 
> Any hint as I'm not at all an HTTP protocol expert.
> 
> --
>    __
>   /  `                          Eric Valette
>  /--   __  o _.                 Canon CRF
> (___, / (_(_(__                 Rue de la touche lambert
>                                 35517 Cesson-Sevigne  Cedex
>                                 FRANCE
> Tel: +33 (0)2 99 87 68 91       Fax: +33 (0)2 99 84 11 30
> E-mail: valette@crf.canon.fr

Hi Eric,
John already told me about your work, great. In RFC 2068 (HTTP/1.1 protocol)
you can read:

10.3.5 304 Not Modified

   If the client has performed a conditional GET request and access is
   allowed, but the document has not been modified, the server SHOULD
   respond with this status code. The response MUST NOT contain a
   message-body.

   The response MUST include the following header fields:
  o  Date
  o  ETag and/or Content-Location, if the header would have been sent in
     a 200 response to the same request
  o  Expires, Cache-Control, and/or Vary, if the field-value might
     differ from that sent in any previous response for the same variant

   If the conditional GET used a strong cache validator (see section
   13.3.3), the response SHOULD NOT include other entity-headers.
   Otherwise (i.e., the conditional GET used a weak validator), the
   response MUST NOT include other entity-headers; this prevents
   inconsistencies between cached entity-bodies and updated headers.

   If a 304 response indicates an entity not currently cached, then the
   cache MUST disregard the response and repeat the request without the
   conditional.

   If a cache uses a received 304 response to update a cache entry, the
   cache MUST update the entry to reflect any new field values given in
   the response.

   The 304 response MUST NOT include a message-body, and thus is always
   terminated by the first empty line after the header fields.

What Netscape version do you use? Can you test the reload with another
browser?
Since I'm also not a HTTP expert I suggest to switch off document caching
meanwhile by including a meta-tag into your HTML-document header:

And I'll look after the problem in the meantime. I checked this with Pi3Web
1.1 (developer release) with Windows 95 OSR 2.5 and Netscape 4.06 and can't
reproduce the problem. I used a own native socket application by turns as
HTTP server and HTTP client with Netscape or Pi3Web on the other end and
found no irregularities until now.
The normal behaviour (how I understand) is, when the client sends a
conditional GET request and the server detects that the cached document
version by the client is still valid, then the server response is a 304
statuscode (Pi3Web handles this as an error but it is more to read as a
status).
I had also a fast look into the HTTPCore.CPP and CondGet.CPP but can't see
suspicious things. Have you checked the following function too?

int HTTPCore_executePhase(
	PIHTTP *pPIHTTP,
	PIObject *(* nextFn)(void *),
	void *pArg )
{
...
		switch( iResult )
			{
...
			case INT_REDIRECT:
				goto done_phase;
			default:
...
done_phase:

	return iResult;
}

-- 
with regards
Holger

---------------------------------------------------------
Holger 'Zimpel' Zimmermann    Contact me:
---------------------------------------------------------
Wendishain                    tel./fax company: on demand
Germany                       tel./fax private: on demand
---------------------------------------------------------
homepage: http://home.t-online.de/home/zimpel/
web server: surf to it from my homepage (online every
            Sunday 20:00-24:00 GMT, start shifted again)
e-Mail:     zimpel@t-online.de
--------------------------------------------------------