Returning a "304 Not Modified" responce

[Hermann]

The standard says "The 304 response MUST NOT contain a message-body,
and thus is always terminated by the first empty line after the header
fields"
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

So in my PHP script I do the time calculations and then I simply do:

header('HTTP/1.1 304 Not Modified') ;
exit ;

But when I retrieve the responce as raw text I see that the responce
does have a body. It is just 8 bytes of binary data and I dont know how
to prevent that from being sent after the headers.

Any idea??

[seaside]

Hermann schrieb:

The standard says "The 304 response MUST NOT contain a message-body,
and thus is always terminated by the first empty line after the header
fields"
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

So in my PHP script I do the time calculations and then I simply do:

header('HTTP/1.1 304 Not Modified') ;
exit ;

But when I retrieve the responce as raw text I see that the responce
does have a body. It is just 8 bytes of binary data and I dont know how
to prevent that from being sent after the headers.

Do you have space, tabs or cr/lf somewhere before <? or after ?>. This
might get posted too.

In general, your header statement gets bigger, since it gets wrapped
inside a valid HTTP header.
I'm sure, you know.

Could you post the source of the header?

[Hermann]

The PHP code I use is the following:
--------------------------------------------------------------------------------------------------
<?
$file=$_SERVER['QUERY_STRING'] ;
$fullFilePath=$_SERVER['DOCUMENT_ROOT'].$file ;
$fileModifiedTime=filemtime($fullFilePath) ;

if($_SERVER['HTTP_IF_MODIFIED_SINCE'])
{ $ifModifiedTime=strtotime($_SERVER['HTTP_IF_MODIFIED_SINCE'],0) ;
if($fileModifiedTime<=$ifModifiedTime)
{ header('HTTP/1.1 304 Not Modified') ;
exit ;
}
}
--------------------------------------------------------------------------------------------------

There is no closing php tag "?>", meaning that not a single byte is
sent to the client.
So I really dont know why are those few bytes being sent after the
headers.
They are just trash, just senseless 1s and 0s. They are always the same
4 bytes.

[Andy Hassall]

On 17 Dec 2006 12:31:08 -0800, "Hermann" <He*************@gmail.comwrote:

>They are just trash, just senseless 1s and 0s. They are always the same
4 bytes.

What bytes are they? They wouldn't happen to be a Unicode Byte Order Mark
(BOM) would they? This would likely not be shown in your editor.

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[Hermann]

Here is the complete responce.
Take a look:
http://img490.imageshack.us/img490/6226/dibujowc7.png

[Andy Hassall]

On 17 Dec 2006 13:33:22 -0800, "Hermann" <He*************@gmail.comwrote:

>Here is the complete responce.
Take a look:
http://img490.imageshack.us/img490/6226/dibujowc7.png

Oh well, so much for my theory then :-)

The partial string "....ecti....K.e" might have originally been "Connection:
Keep-Alive" in whatever memory location it came from, but that doesn't help
much.

--
Andy Hassall :: an**@andyh.co.uk :: http://www.andyh.co.uk
http://www.andyhsoftware.co.uk/space :: disk and FTP usage analysis tool

[seaside]

Hermann schrieb:

Here is the complete responce.
Take a look:
http://img490.imageshack.us/img490/6226/dibujowc7.png

Hm, this doesn't look that bad. The 0d0a0d0a marks the end of the
header as expected.

Are you absolutely sure, that the additional bytes are really at the
end of the data? Or does your packet-sniffer always print full rows of
data?

In case you could post a sample URL, I'm happy to verify from over here.

[seaside]

Hermann schrieb:

Here is the complete responce.
Take a look:
http://img490.imageshack.us/img490/6226/dibujowc7.png

Oh, forgot to mention:

Since your HTTP reply doesn't contain a Content-length property like
this

Content-length: 327

it ends at the 0d0a0d0a. So, everything seems to be fine.

[Hermann]

You are right. It actually seems to be working pretty well.

My HTTP sniffer always show complete rows so it is probably nothing to
worry about.

Thank you all for your replies.