Re: [PHP] Re: PHP script lag (5 secs) when declaring mime type.

[9el]

On Fri, Mar 6, 2009 at 4:18 PM, Jsbeginner wrote:

> Thankyou for the help,
>
> I will contact the script maintainer to ask him to work on this problem for
> future updates, and for the moment I've commented out the line that
> specifies the length.
> I suppose that it won't cause any problems with files that are sent through
> this script that are not gzipped (this script allows html, js, css (all
> compressed with gzip) as well as images that aren't compressed.
>
> From what I understand the best would be to detect if gzip is activated for
> each file and only allow the header to specify the length if the file is not
> planned to be compressed with gzip (images etc).


As we discussed, the declaration of size of the file is COMPLETELY
unnecessary in this case.
Lenin  www.twitter.com/nine_L

>
>
> Thanks again :)
>
> Nisse Engström a écrit :
>
>  On Thu, 5 Mar 2009 19:14:20 +0100, Nisse Engström wrote:
>>
>>
>>
>>> On Thu, 05 Mar 2009 15:45:35 +0100, Jsbeginner wrote:
>>>
>>>
>>>
 >>> header('Content-Type: application/x-javascript');
 header('Content-Length: '.filesize('test.js'));
 readfile('test.js');
 ?>

 test.js is only a few lines long, and if I remove the header content
 type the file loads instantaniously do it's not a problem with readfile.
 I thought about zlib gzip taking maybe a long time to load but I've
 changed the compression level from 6 to 1 and the file still has a the same
 lag.


>>> Content-Length MUST NOT be sent when using a
>>> Transfer-Encoding (eg. gzip).
>>>
>>> See: 
>>>
>>>
>>
>> And I goofed: Transfer-Encoding is the stuff that says
>> "chunked". I was thinking of Content-Encoding. But the
>> section I refered to also says:
>>
>>  "If a Content-Length header field (section 14.13) is present, its
>>   decimal value in OCTETs represents both the entity-length and the
>>   transfer-length. The Content-Length header field MUST NOT be sent
>>   if these two lengths are different"
>>
>> [And a little further down, it mentions "that the
>>  recipient can arse it". I'm not sure quite what
>>  to make of that. :-)]
>>
>>  -   -   -
>>
>> Come to think about it, I've written some output handlers
>> to convert utf-8 to utf-16 or -32, which uses either
>> 'Content-Length' or 'Transfer-Encoding: chunked' depending
>> on the size of the output. Perhaps I should change that to
>> always 'chunked'...
>>
>>
>> /Nisse
>>
>>
>>
>
>

Re: [PHP] Re: PHP script lag (5 secs) when declaring mime type.

[Jsbeginner]

Thankyou for the help,

I will contact the script maintainer to ask him to work on this problem 
for future updates, and for the moment I've commented out the line that 
specifies the length.
I suppose that it won't cause any problems with files that are sent 
through this script that are not gzipped (this script allows html, js, 
css (all compressed with gzip) as well as images that aren't compressed.


From what I understand the best would be to detect if gzip is activated 
for each file and only allow the header to specify the length if the 
file is not planned to be compressed with gzip (images etc).


Thanks again :)

Nisse Engström a écrit :

On Thu, 5 Mar 2009 19:14:20 +0100, Nisse Engström wrote:

  

On Thu, 05 Mar 2009 15:45:35 +0100, Jsbeginner wrote:





test.js is only a few lines long, and if I remove the header content 
type the file loads instantaniously do it's not a problem with readfile.
I thought about zlib gzip taking maybe a long time to load but I've 
changed the compression level from 6 to 1 and the file still has a the 
same lag.
  

Content-Length MUST NOT be sent when using a
Transfer-Encoding (eg. gzip).

See: 



And I goofed: Transfer-Encoding is the stuff that says
"chunked". I was thinking of Content-Encoding. But the
section I refered to also says:

  "If a Content-Length header field (section 14.13) is present, its
   decimal value in OCTETs represents both the entity-length and the
   transfer-length. The Content-Length header field MUST NOT be sent
   if these two lengths are different"

[And a little further down, it mentions "that the
 recipient can arse it". I'm not sure quite what
 to make of that. :-)]

 -   -   -

Come to think about it, I've written some output handlers
to convert utf-8 to utf-16 or -32, which uses either
'Content-Length' or 'Transfer-Encoding: chunked' depending
on the size of the output. Perhaps I should change that to
always 'chunked'...


/Nisse