Re: [PHP] GZip: NS or HTTP/1.0
On Fri, Mar 30, 2001 at 08:06:21AM -0600, Brad S. Jackson wrote: I've tested the ob_gzhandler with PHP 4.0.4pl1 and Netscape 4.76 and it works fine for me. I don't know why some people have problems. I doubt it has anything to do with HTTP 1.1 and this can be tested by disabling 1.1 support in the IE advanced options. I think compression is controlled entirely by the browser sending an Accept-Encoding: gzip header and the server responding with a Content-Encoding: gzip header. It's possible that the server is compressing with the deflate method, which I think Netscape doesn't support. Well I never said that NS doesn't support compression. Using the gzhandler works just fine with NS. The problem hower is a different one. The page is shown perfectly, but when you try to print it, NS 'forgets'(?) to decompress it. _That's_ what's wrong. Another thing is 'view source'. Then (I think) NS doesn't decompress either, 'cause NS then says that the document is 'Untitled' and no code is shown _at all_. And for the HTTP-thing I started You're exactly right! Painful to see the answer on a question and notice that the answer is _SO SIMPLE_. "Just go to Tools, go to Internet Options, go to Advanced, disabled 'Use HTTP/1.1'". G, and then knowing that I've been developping and testing for years now. Something so extremely simple, and I just _DID NOT THINK ABOUT IT_. Anyway... I disabled it and it makes no difference. Conclusion (for now...): HTTP/1.0 is not the problem, NS is. Another lovely bug from the NS-services. So This was a pretty useless try from me. Thanks for attending me to the very basics of IE-testing (...) -- * RzE: *** ** Renze Munnik ** ** E: [EMAIL PROTECTED] ** M: +31 6 218 111 43 *** -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] GZip: NS or HTTP/1.0
I don't think it's anything to do with HTTP 1.0 or 1.1.
It's simply the fact that NS gets a copy of the website for
everything, all the time. Resized the window? OOPS! Guess
I need a new copy of the file I just got 5 seconds ago! Stupid
stupid stupid.
I think it's simply down to the fact that no one ever thought
someone would print out a compressed web page, and they never
tested it. Seeing how long it takes the mozilla project to do anything,
my guess is confirmed more and more as I see no good bug checking
or testing before releases are made. Couple that with the feature
bloat and mission creep, you can see why something as trivial as
PRINTING never got thoroughly tested. But MathML. Wow!
We sure need that...
I'm not dogging all open source stuff. Apache is still chugging away just
nicely,
making good progress, imo. Linux? Of course. And PHP. In the time
since mozilla was announced, PHP went from 3 to 4, had numerous
upgrades, had a company formed around it(!) and has created a new industry
and standard around it. All because of a relative handful of dedicated
people
with a common goal.
Stopping my rant now...
Renze Munnik wrote:
Okay guys I've got a new idea
I just found out that NS5 uses HTTP/1.0 and not HTTP/1.1. Well,
okay, but that's not _to_ exciting is it?! But... (there's always a
'but') IE=5 uses HTTP/1.1. Now, looking back at the subject being
discussed in this thread, I'm wondering if that might be the problem
that arises when using the gzhandler.
Example
On our server we use the multi-views: no extensions required! So,
instead of calling 'page.php' I just call 'page'. Nothing wrong with
that, not even for NS. But... (there it is again!) I made the
following (test) page:
HTML
HEAD
TITLEPHP Info/TITLE
STYLE type="text/css"
BODY {
background-color: #ff;
}
/STYLE
/HEAD
BODY
? phpinfo(); ?
/BODY
/HTML
I've named this file 'php-info.php'. So... Now I call this page from
IE (5) calling 'php-info'. Guess what? Nothing wrong; works
perfectly! And now the big NS test. S*cks!!! Calling 'php-info' from
NS provides me the next error:
..."no acceptable variant: "...
This error is server-side and only occurs when using HTTP/1.0. So I
was wondering if the HTTP/1.0 can also be the cause of the printing
problem concering the gzhandler?
If that's the case I should disable the compression for each and
every browser that uses HTTP/1.0 instead of only disabling it for
NS.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] GZip: NS or HTTP/1.0
On Fri, Mar 30, 2001 at 09:53:53AM -0500, Michael Kimsal wrote: You REALLY don't want to specifically ignore Netscape users, do you? :) Any browser that can accept gzipped stuff sends a content-accept header. Netscape tells the server it can handle gzipped stuff, so the server can send it. Other browsers (HTTP 1.0, 1.1, or whatever) can choose to tell the server what they can accept, regardless of HTTP version. Netscape can handle the gzipped stuff just fine - they prove it by rendering it. It's simply their printing logic which is messed up. Face it - just disable gzipping for Netscape users. JUST DO IT! Anyone else who can't handle gzipped stuff will have the good sense to not announce that it can accept it in the headers. Renze Munnik wrote: This error is server-side and only occurs when using HTTP/1.0. So I was wondering if the HTTP/1.0 can also be the cause of the printing problem concering the gzhandler? If that's the case I should disable the compression for each and every browser that uses HTTP/1.0 instead of only disabling it for NS. Hi there Michael, Eh... No! 'Course I'm not gon' ignore all NS users. I'm just gon' disable compress'n f'r 'm. I nev'r had ( nev'r will have) the intens'n of blocking 'm out. But I explicitly off'r the poss. of print'n out the page, so it must always work. As long as I enable compress'n, NS-us'rs can't print the page. So... no compress'n for 'm. Or someone sh'ld have a bett'r idea. I mean... NS s'nds the head'r tellin' my serv'r that it supp'rts gzip - my serv'r then s'nds the compress'd page - then NS rememb'rs it doesn't want to decompr'ss it and prints the compr'ss'd sh!t. And bring'n up the whole HTTP-thin' was a stupid idea from my side. Just forg't to t'st my "theory" prop'rly. Sorry!! So... f'r n'w I'm g'nna disable compr'ssion f'r NS-us'rs, 'till someone has anoth'r solut'n. [sorry 'bout all them '-s, but I'm working to long today] -- * RzE: *** ** Renze Munnik ** ** E: [EMAIL PROTECTED] ** M: +31 6 218 111 43 *** -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
