You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by Stas Bekman <st...@stason.org> on 2002/06/05 18:44:44 UTC
tutorials (was: Re: rfc Apache::Dynagzip)
Per Einar Ellefsen wrote:
> At 15:36 05.06.2002, Valerio_Valdez Paolini wrote:
>
>> On Tue, 4 Jun 2002, Slava Bizyayev wrote:
>>
>> > I don't know should it be a kitchen of every system administrator, or
>> > somebody could volunteer to serve the public web site about the current
>> > conditions of different web clients and recommended masks?.. I can't
>> host it
>> > on my devl4, because it is a development machine. That would be
>> better to
>> > find some stable place, like mod_perl, or apache project ;-).
>>
>> Can you provide a compatibility list? I think that the new mod_perl site
>> is looking for new articles, may be the first part of Apache::Dynagzip
>> man page is a good candidate... You could add also known bugs and
>> features. But I cannot decide what goes on mod_perl site :)
>
>
> Just like I would have said it myself :-) We're clearly looking for
> information, and I was especially watching this thread for possible
> inclusion. We have a nice place to do this, it's in our "Browser bugs"
> section. Depending on the size of the document, it might go there or in
> its own doc. Anyway, we welcome any submissions. Format is standard Pod.
> See
> http://cvs.apache.org/viewcvs.cgi/modperl-docs/admin/style.pod?rev=1.8&content-type=text/vnd.viewcvs-markup
> for style information, but don't worry too much about that, we'll fix
> that as we go.
I just want to add some clarifications to Per Einar comment.
Are we looking for not strictly mod_perl but closely related material,
which matters to the majority of mod_perl programmers?
The short answer:
Tutorials -> yes
manpages -> no
articles -> take23.org
The long answer:
Tutorials cover some interesting topics using several implementations.
Tutorials are pretty much static and don't require much maintenance. We
heartly welcome these. The ongoing discission of MVC is a good example
of a tutorial candidate, templating comparison and *generic* tips and
tricks are other ones.
Manpages, which aren't the core module are not very welcome at this
moment, as they usually require high level of maintenance, and we have
hardly resources to cope with perl.apache.org. So at least for now,
manpages aren't welcome.
If you have feature tutorials, either submit those to take23.org or any
other online zine. perl.com is looking for such articles. so does
apacheweek.com. probable there are others.
The new perl.apache.org is not a dump place for docs. The more
irrelevant stuff we throw there the less added value the site will have,
the harder it'll be to find something and the whole idea of expanding
docs will do more bad than good. So new tutorials are definitely
welcome, but re-read the first para to see the definition of a good
candidate and so the existing tutorials at:
http://perl.apache.org/release/docs/tutorials/index.html
before submitting your tutorial. If your idea of tutorial doesn't fit
into perl.apache.org's tutorial's idea, we will gladly link to it.
---
Now back to the topic. If you can submit to us known problems with
browsers and solutions that would be great. But please don't submit the
Apache::Dynagzip manpage.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Slava Bizyayev <sb...@outlook.net>.
devl4 is up and running since now.
Thanks for your patience,
Slava
----- Original Message -----
From: "Slava Bizyayev" <sb...@outlook.net>
To: "Slava Bizyayev" <sb...@outlook.net>; "Stas Bekman"
<st...@stason.org>; "modperl list" <mo...@apache.org>
Sent: Wednesday, June 12, 2002 6:59 PM
Subject: Re: tutorials (was: Re: rfc Apache::Dynagzip)
> Sorry folks,
>
> I experience some access problems with devl4. Server is down temporarily.
> I'll let you know when ready to continue.
>
> Slava
>
> ----- Original Message -----
> From: "Slava Bizyayev" <sb...@outlook.net>
> To: "Stas Bekman" <st...@stason.org>; "modperl list" <mo...@apache.org>
> Sent: Wednesday, June 12, 2002 5:04 PM
> Subject: Re: tutorials (was: Re: rfc Apache::Dynagzip)
>
>
> >
> > From: "Stas Bekman" <st...@stason.org>
> > Subject: Re: tutorials (was: Re: rfc Apache::Dynagzip)
> >
> >
> > > Probably the best post it here first, so we can get it reviewed and
> > > commented on before we add it to the docs.
> >
> > Since now the draft tutorial "Features of Content Compression for
> Different
> > Web Clients" (for Part IV: Client side facts and bugs) is available for
> > preview and discussion at
> > http://devl4.outlook.net/devdoc/Dynagzip/ContentCompressionClients.html
.
> >
> > I strongly hope to make it much better with your help prior to submit
for
> > publishing. Any comments will be highly appreciated.
> >
> > Thanks in advance,
> > Slava
> >
> >
> >
>
>
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Slava Bizyayev <sb...@outlook.net>.
Sorry folks,
I experience some access problems with devl4. Server is down temporarily.
I'll let you know when ready to continue.
Slava
----- Original Message -----
From: "Slava Bizyayev" <sb...@outlook.net>
To: "Stas Bekman" <st...@stason.org>; "modperl list" <mo...@apache.org>
Sent: Wednesday, June 12, 2002 5:04 PM
Subject: Re: tutorials (was: Re: rfc Apache::Dynagzip)
>
> From: "Stas Bekman" <st...@stason.org>
> Subject: Re: tutorials (was: Re: rfc Apache::Dynagzip)
>
>
> > Probably the best post it here first, so we can get it reviewed and
> > commented on before we add it to the docs.
>
> Since now the draft tutorial "Features of Content Compression for
Different
> Web Clients" (for Part IV: Client side facts and bugs) is available for
> preview and discussion at
> http://devl4.outlook.net/devdoc/Dynagzip/ContentCompressionClients.html .
>
> I strongly hope to make it much better with your help prior to submit for
> publishing. Any comments will be highly appreciated.
>
> Thanks in advance,
> Slava
>
>
>
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Slava Bizyayev <sb...@outlook.net>.
From: "Igor Sysoev" <is...@rambler-co.ru>
> Yes, your response is really cached at least in MSIE 5.5.
Thanks.
...............
> I mean that handler can do following:
>
> if ($r->headers_in("Accept-Encoding") =~ /gzip/
> and not $r->note("disable_gzip"))
> {
> do gzipping
> }
Should we consider this the only possible way to write compression handlers?
Folks used to implement some different approach (clear and simple), common
to all mod_perl compressors listed in the tutorial. It works fine. See
sources for details.
Thanks,
Slava
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Igor Sysoev <is...@rambler-co.ru>.
On Tue, 18 Jun 2002, Slava Bizyayev wrote:
> Igor seems upset with the current (not still final) results of this
> discussion, which HE tried to turn selfishly to a wrong way. Impolite style
> of discussions accomplished with attempts to hide some information and to
> provide some fantasies instead of real results of professional research does
> not work on this professional mailing list.
What you call "impolite style" is simlpy poor English. It's very hard
to me to express my thoughts in correct and polite English.
> That's right, instead of the main discussion we've spent a lot of time to
> learn a lesson, how the impolite selfish guy playing fool with professionals
> is punished finally, but wasn't it a fun? Ok, let me consider the lesson is
> over, and we may now go back to the main subject of this discussion.
Yes, Beavis, it was a fun !
(I bag pardon to all subscribers, I can not resist, it's last personal email)
Igor Sysoev
http://sysoev.ru
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Slava Bizyayev <sb...@outlook.net>.
It's not quite the truth again. It is not a private email; it is a public
mailing list. Everyone writing here expects the replies and comments from
any other subscriber, especially from the main speaker of the thread.
Igor seems upset with the current (not still final) results of this
discussion, which HE tried to turn selfishly to a wrong way. Impolite style
of discussions accomplished with attempts to hide some information and to
provide some fantasies instead of real results of professional research does
not work on this professional mailing list.
That's right, instead of the main discussion we've spent a lot of time to
learn a lesson, how the impolite selfish guy playing fool with professionals
is punished finally, but wasn't it a fun? Ok, let me consider the lesson is
over, and we may now go back to the main subject of this discussion.
Just a few important conclusions: It's nothing bad to be wrong, or to make
mistakes. Everyone does sometimes. We join our efforts, knowledge, and
expertise in discussions to help each other to make every job well done with
full respect of efforts, knowledge, and expertise of every participant. That
's why we can compete successfully in this world. I firmly believe that Igor
will be back in our discussions soon, equipped with right behavior, and no
one of us will ever mention his old mistake.
Thanks,
Slava
From: "Igor Sysoev" <is...@rambler-co.ru>
>
> It was my reply to Valerio_Valdez. He had asked me why I need logging.
> I had answered him. You said me once again about another ways of logging.
> I know them. Thank you.
>
> I do not try to dictate anyone my needs or fantasies.
> Relax and do anything in fixup handler and tutorial - I would try
> not disturb you in any way and hope that is the last my email
> on this subject.
>
> Igor Sysoev
> http://sysoev.ru
>
>
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Igor Sysoev <is...@rambler-co.ru>.
On Mon, 17 Jun 2002, Slava Bizyayev wrote:
> Yes, absolutely. And no one on the earth may restrict your rights to log
> anything you feel important in your own handler. Just every overhead
> decrements the number of your prospective users. And when you try to dictate
> your very own needs (or fantasies) to be accepted as a standard, you are
> incorrect.
It was my reply to Valerio_Valdez. He had asked me why I need logging.
I had answered him. You said me once again about another ways of logging.
I know them. Thank you.
I do not try to dictate anyone my needs or fantasies.
Relax and do anything in fixup handler and tutorial - I would try
not disturb you in any way and hope that is the last my email
on this subject.
Igor Sysoev
http://sysoev.ru
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Slava Bizyayev <sb...@outlook.net>.
Oooops!
Would you mind to keep your client unaware about some uncertainties in our
pseudo-technical talks?
Thanks,
;-) Slava
On Mon, 17 Jun 2002, Ged Haywood wrote:
> Hi there,
>
> On Mon, 17 Jun 2002, Slava Bizyayev wrote:
>
> > And no one on the earth may restrict your rights to log anything you
> > feel important in your own handler.
>
> Don't be too sure about that.
>
> There are for example privacy laws in both Europe and the USA which
> impinge upon this, and at least one of my Clients has spent a lot of
> time and money on it.
>
> 73,
> Ged.
>
>
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Ged Haywood <ge...@www2.jubileegroup.co.uk>.
Hi there,
On Mon, 17 Jun 2002, Slava Bizyayev wrote:
> And no one on the earth may restrict your rights to log anything you
> feel important in your own handler.
Don't be too sure about that.
There are for example privacy laws in both Europe and the USA which
impinge upon this, and at least one of my Clients has spent a lot of
time and money on it.
73,
Ged.
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Slava Bizyayev <sb...@outlook.net>.
From: "Igor Sysoev" <is...@rambler-co.ru>
> > > I simply log it to see changes in the browsers.
> > > I really do it on my frontends that compress content.
> >
> > There are no problem to log any data from any stage of the request
> > processing. See Eagle Book and/or Cook Book for details. Let me just
point
> > out that the problem of clients' research is closely related to the
content
> > compression implementation, but it's a very different problem with many
> > features which we should take into account when we are serious about
results
> > of our work in content compression. I would prefer to separate the
content
> > compression from the clients' research. We develop content compression
> > handlers, targeting busy production servers where we would like to
update
> > our handlers rarely. The research system should be very flexible to
serve
> > our current needs in clients' investigations. It should be easy
updateable
> > anytime, and should not overhead production servers on each request.
That's
> > why I'm calling again for volunteers to host and develop the appropriate
> > tool-site. We'll be speaking about this soon again. (I'm still in
process of
> > verification of the rest of the points of Igor's criticisms. I'll be
back to
> > discussion as soon as I get ready with them.)
>
> The problem that real-life clients go to busy production sites but not
> to research sites. They simply do not know about them.
> As to logging \"%{Accept-Encoding}i\" has no more overhead than
> \"%{User-Agent}i\" that usually set in access_log.
Yes, absolutely. And no one on the earth may restrict your rights to log
anything you feel important in your own handler. Just every overhead
decrements the number of your prospective users. And when you try to dictate
your very own needs (or fantasies) to be accepted as a standard, you are
incorrect.
Thanks,
Slava
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Igor Sysoev <is...@rambler-co.ru>.
On Mon, 17 Jun 2002, Slava Bizyayev wrote:
> From: "Igor Sysoev" <is...@rambler-co.ru>
>
> > > > I mean that handler can do following:
> > > >
> > > > if ($r->headers_in("Accept-Encoding") =~ /gzip/
> > > > and not $r->note("disable_gzip"))
> > > > {
> > > > do gzipping
> > > > }
> > >
> > > I understand your point of view, even I prefer Slava's approach.
> > > I'm asking myself why you will need to log that particular header.
> > > It is not a provocation, I don't understand the usefulness of
> > > logging the status of an header that can be deduced undoubtedly from
> > > the signature of browser issuing the request.
> >
> > I simply log it to see changes in the browsers.
> > I really do it on my frontends that compress content.
>
> There are no problem to log any data from any stage of the request
> processing. See Eagle Book and/or Cook Book for details. Let me just point
> out that the problem of clients' research is closely related to the content
> compression implementation, but it's a very different problem with many
> features which we should take into account when we are serious about results
> of our work in content compression. I would prefer to separate the content
> compression from the clients' research. We develop content compression
> handlers, targeting busy production servers where we would like to update
> our handlers rarely. The research system should be very flexible to serve
> our current needs in clients' investigations. It should be easy updateable
> anytime, and should not overhead production servers on each request. That's
> why I'm calling again for volunteers to host and develop the appropriate
> tool-site. We'll be speaking about this soon again. (I'm still in process of
> verification of the rest of the points of Igor's criticisms. I'll be back to
> discussion as soon as I get ready with them.)
The problem that real-life clients go to busy production sites but not
to research sites. They simply do not know about them.
As to logging \"%{Accept-Encoding}i\" has no more overhead than
\"%{User-Agent}i\" that usually set in access_log.
Igor Sysoev
http://sysoev.ru
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Slava Bizyayev <sb...@outlook.net>.
From: "Igor Sysoev" <is...@rambler-co.ru>
> > > I mean that handler can do following:
> > >
> > > if ($r->headers_in("Accept-Encoding") =~ /gzip/
> > > and not $r->note("disable_gzip"))
> > > {
> > > do gzipping
> > > }
> >
> > I understand your point of view, even I prefer Slava's approach.
> > I'm asking myself why you will need to log that particular header.
> > It is not a provocation, I don't understand the usefulness of
> > logging the status of an header that can be deduced undoubtedly from
> > the signature of browser issuing the request.
>
> I simply log it to see changes in the browsers.
> I really do it on my frontends that compress content.
There are no problem to log any data from any stage of the request
processing. See Eagle Book and/or Cook Book for details. Let me just point
out that the problem of clients' research is closely related to the content
compression implementation, but it's a very different problem with many
features which we should take into account when we are serious about results
of our work in content compression. I would prefer to separate the content
compression from the clients' research. We develop content compression
handlers, targeting busy production servers where we would like to update
our handlers rarely. The research system should be very flexible to serve
our current needs in clients' investigations. It should be easy updateable
anytime, and should not overhead production servers on each request. That's
why I'm calling again for volunteers to host and develop the appropriate
tool-site. We'll be speaking about this soon again. (I'm still in process of
verification of the rest of the points of Igor's criticisms. I'll be back to
discussion as soon as I get ready with them.)
Thanks,
Slava
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Igor Sysoev <is...@rambler-co.ru>.
On Fri, 14 Jun 2002, Valerio_Valdez Paolini wrote:
> On Sat, 15 Jun 2002, Igor Sysoev wrote:
>
> > I mean that handler can do following:
> >
> > if ($r->headers_in("Accept-Encoding") =~ /gzip/
> > and not $r->note("disable_gzip"))
> > {
> > do gzipping
> > }
>
> I understand your point of view, even I prefer Slava's approach.
> I'm asking myself why you will need to log that particular header.
> It is not a provocation, I don't understand the usefulness of
> logging the status of an header that can be deduced undoubtedly from
> the signature of browser issuing the request.
I simply log it to see changes in the browsers.
I really do it on my frontends that compress content.
Igor Sysoev
http://sysoev.ru
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Valerio_Valdez Paolini <pa...@students.cs.unibo.it>.
On Sat, 15 Jun 2002, Igor Sysoev wrote:
> I mean that handler can do following:
>
> if ($r->headers_in("Accept-Encoding") =~ /gzip/
> and not $r->note("disable_gzip"))
> {
> do gzipping
> }
I understand your point of view, even I prefer Slava's approach.
I'm asking myself why you will need to log that particular header.
It is not a provocation, I don't understand the usefulness of
logging the status of an header that can be deduced undoubtedly from
the signature of browser issuing the request.
Ciao, Valerio
Valerio Paolini, <http://130.136.3.200/~paolini>
--------------------------------------------------
what is open-source about? Learn, and then give back
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Igor Sysoev <is...@rambler-co.ru>.
On Fri, 14 Jun 2002, Slava Bizyayev wrote:
> From: "Igor Sysoev" <is...@rambler-co.ru>
>
> > Can you show me URL with "Vary" and "Expires" that MSIE would cache.
>
> You have this combination when you access my preview with your MSIE by
> HTTP/1.1 with no proxy (it's still old version of
Yes, your response is really cached at least in MSIE 5.5.
I have just investigate this.
Responses with "Vary: Accept-Encoding" and "Content-Encoding: gzip"
are cached by MSIE. The "Expires" header is not needed.
Responses with "Vary: Accept-Encoding" but without "Content-Encoding: gzip"
are not cached by MSIE.
Furthermore, responses with "Vary: Any,dummy,words" and
"Content-Encoding: gzip" are also cached by MSIE.
And as I said before responses with "Vary: Any,dummy,words" and
without "Content-Encoding: gzip" are not cached by MSIE.
All these was tested with MSIE 5.5 only.
> > > > > > 4. You should not unset "Accept-Encoding". Better way is to set
> > > > > > $r->note('disable_gzip').
> > > > >
> > > > > Sometimes it seems like Igor does not really understand what he is
> > > speaking
> > > > > about. No comments.
> > > >
> > > > I mean that that you should not change any incoming header.
> > >
> > > ?! No comments.
> >
> > How can I log a real "Accept-Encoding" header if you unset it ?
>
> There is more than one way to do this, using mod_perl.
I mean that handler can do following:
if ($r->headers_in("Accept-Encoding") =~ /gzip/
and not $r->note("disable_gzip"))
{
do gzipping
}
Igor Sysoev
http://sysoev.ru
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Slava Bizyayev <sb...@outlook.net>.
From: "Igor Sysoev" <is...@rambler-co.ru>
> Can you show me URL with "Vary" and "Expires" that MSIE would cache.
You have this combination when you access my preview with your MSIE by
HTTP/1.1 with no proxy (it's still old version of
Apache::CompressClientFixup installed over there). The lifetime of local
cache is 5 minutes, defined by my Expires. Within this time the browser will
not even try to access the server when you try to reach the same URL.
Instead, it restarts the page from the local cache. It's important to point
out that all initial JavaScripts will be restarted indeed, so you can rotate
your advertisements and dynamic content when needed. The second important
point should be mentioned here: when you click the "Refresh" button, the
browser will reload the page from the server unconditionally. It's right,
because it is exactly what the end-user expects from the "Refresh" button.
It was tested several times on my commercial handlers. It works fine
anywhere (I mean no problem is reported to date). The only issue was
mentioned by our testers: the lifetime depends on time accuracy of client
side. If your local client's clock is running 1 hour back, the cached copy
of my preview will be alive 65 minutes on that machine...
> > > > > 4. You should not unset "Accept-Encoding". Better way is to set
> > > > > $r->note('disable_gzip').
> > > >
> > > > Sometimes it seems like Igor does not really understand what he is
> > speaking
> > > > about. No comments.
> > >
> > > I mean that that you should not change any incoming header.
> >
> > ?! No comments.
>
> How can I log a real "Accept-Encoding" header if you unset it ?
There is more than one way to do this, using mod_perl.
Thanks,
Slava
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Igor Sysoev <is...@rambler-co.ru>.
On Fri, 14 Jun 2002, Slava Bizyayev wrote:
> > I did not check how Squid work with Vary header because any value in
> > this header simply disables caching in MSIE. I prefer client caching
> > to compression.
>
> It's not the truth again. I'm using Vary accomplished with Expires to
> control MSIE local cache about half a year. Works fine.
I have just checked 3 MSIE:
Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0; T312461)
Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; Q312461)
All of them had recevied responses like this:
HTTP/1.1 200 OK
Date: Fri, 14 Jun 2002 09:51:59 GMT
Server: Apache/1.3.22 (Unix)
Vary: Content-Encoding
Cache-Control: max-age=86400
Expires: Sat, 15 Jun 2002 09:51:59 GMT
Last-Modified: Tue, 09 Apr 2002 14:15:31 GMT
ETag: "1d3a9-65d-3cb2f783"
Accept-Ranges: bytes
Content-Length: 1629
Connection: close
Content-Type: text/html; charset=koi8-r
All of MSIE do not cache responses. They even do not
send "If-Modified-Since" header.
Can you show me URL with "Vary" and "Expires" that MSIE would cache.
> > > > 4. You should not unset "Accept-Encoding". Better way is to set
> > > > $r->note('disable_gzip').
> > >
> > > Sometimes it seems like Igor does not really understand what he is
> speaking
> > > about. No comments.
> >
> > I mean that that you should not change any incoming header.
>
> ?! No comments.
How can I log a real "Accept-Encoding" header if you unset it ?
Igor Sysoev
http://sysoev.ru
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Slava Bizyayev <sb...@outlook.net>.
From: "Igor Sysoev" <is...@rambler-co.ru>
Sent: Friday, June 14, 2002 3:53 AM
Subject: Re: tutorials (was: Re: rfc Apache::Dynagzip)
> I did not check how Squid work with Vary header because any value in
> this header simply disables caching in MSIE. I prefer client caching
> to compression.
It's not the truth again. I'm using Vary accomplished with Expires to
control MSIE local cache about half a year. Works fine.
> > > 4. You should not unset "Accept-Encoding". Better way is to set
> > > $r->note('disable_gzip').
> >
> > Sometimes it seems like Igor does not really understand what he is
speaking
> > about. No comments.
>
> I mean that that you should not change any incoming header.
?! No comments.
Thanks,
Slava
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Igor Sysoev <is...@rambler-co.ru>.
On Fri, 14 Jun 2002, Slava Bizyayev wrote:
> Does it make sense? For me it means that every fact which is coming from
> Igor Sysoev should be double-checked independently prior to practical usage.
OK. It's your right.
> I guess some significant changes in the next version of the tutorial... On
> other hand, I feel better, knowing that guys from Squid are caring about our
> clients, and life goes on.
I did not check how Squid work with Vary header because any value in
this header simply disables caching in MSIE. I prefer client caching
to compression.
> > 4. You should not unset "Accept-Encoding". Better way is to set
> > $r->note('disable_gzip').
>
> Sometimes it seems like Igor does not really understand what he is speaking
> about. No comments.
I mean that that you should not change any incoming header.
Igor Sysoev
http://sysoev.ru
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Slava Bizyayev <sb...@outlook.net>.
From: "Igor Sysoev" <is...@rambler-co.ru>
> Here is first part of criticism.
>
> 1. You should not mix proxies and browsers.
It's a question. I've been thinking about this, and decided to refrain from
diving into a long common discussion about features of spiders,
content-feeders, general indexing robots, etc. I wouldn't let reader to sink
in unhelpful features of specific web clients before giving him a real tool
to serve those guys in accordance with his own business requirements (which
could be opposite to my own preferences). I firmly believe that we'll have
to deal with those guys in future. To make it practically helpful we have to
study all possible features of all available web clients on permanent basis,
and keep the community informed about current conditions of network clients.
To date we have too limited number of practically useful facts to stick with
this problem. Even more, we have to double-check some of "well-known" facts,
because the life is going on. New versions of old known web clients are
emerging sometimes. Sometimes people can make mistakes. Everything is going
to be changed on the earth, including the structure of this tutorial.
> 2. As I said you MS Proxy has not mask at all. "^1\.1 " is not a mask.
> "^Squid/" is incorrect mask.
> Here is example of Via header of HTTP/1.1 request that goes
> though Squid, MS Proxy and Oops:
>
> "1.1 proxy1.domain1.com:3128 (Squid/2.4.STABLE2), 1.0 PROXY2,
> proxy3.domain3.com:3128 (Oops 1.5.22f1)"
>
> 3. Proxy masks will not help. About 70% of all proxied request are going
> through Squid and about 15% are going through MS Proxy.
> So much safe way is to disable proxy requests at all instead of tring
> to look mask.
> Besides I suspect that most proxies handle compressed content
incorrectly.
> I had checked only Squid, MS Proxy and Oops but there are many another
> proxies. So I think you should disable gzip for all proxied request
> or enable it for all proxied request if you do not care about old
broswer.
> mod_deflate by default disable it.
Since Igor fails to explain clearly the features of his "secret knowledge"
in both English and Russian to me, I decided to double-check his information
with the source authorities. Indeed, I was lucky to have a short
conversation on squid-users@squid-cache.org mailing list with Henrik
Nordstrom, who is developing the Squid proxy. Now I have a real mask for the
Apache::CompressClientFixup handler and some new conditions for successful
implementation of content compression, serving the requests passed through
Squid. I'm going to make the appropriate changes in the text of tutorial as
version 0.02 a few days later together with other changes. Just a little
fragment of my conversation with Henrik Nordstrom for those who care:
From: "Henrik Nordstrom" <X>
Sent: Thursday, June 13, 2002 7:15 PM
Subject: Re: [squid-users] "Accept-Encoding" header
# Squid-2.5 and later supports caching of objects having the Vary
# header.
#
# Squid-2.4 and earlier denies caching of such objects as it cannot
# support more than one entity per URL.
On Friday 14 June 2002 02:43, Slava Bizyayev wrote:
# Should we consider the Squid-2.4 the only version compatible with
# content compression (as long as it denies to cache anything
# accomplished with Vary header)?
#
# Please, could you specify the earliest version, which is working
# this way?
#
# Am I understand correctly that we should refrain from
# doing the content compression on httpd when the request is coming
# through the Squid-2.5 (even we reply with Vary)?
From: Henrik Nordstrom <X>
Date: Fri, 14 Jun 2002 02:57:01 +0200
Subject: Re: [squid-users] "Accept-Encoding" header
# Both are fully compatible with all forms of server driven content
# negotiation (file type, encoding, compression etc), as long as you
# send a proper Vary header indicating such negotiation is taking
# place.
#
# Squid-2.4 and earlier won't be able to cache the reply as Squid-2.4
# and earlier can only support up to one entity version per URL.
#
# Squid-2.5 will cache the reply if possible, and honors the entity
# variance indicated by Vary.
#
# Squid-2.6 will most likely also support ETag, allowing Squid to ask
# the server which if any of the variants it already has is suitable
# for satisfying the new request type. In Squid-2.5 each request type
# is cached individually.
#
# The detection of Vary as uncacheable was added very long ago, probably
# during the Squid-1.X versions.
#
# Regards
# Henrik
Does it make sense? For me it means that every fact which is coming from
Igor Sysoev should be double-checked independently prior to practical usage.
I guess some significant changes in the next version of the tutorial... On
other hand, I feel better, knowing that guys from Squid are caring about our
clients, and life goes on.
> 4. You should not unset "Accept-Encoding". Better way is to set
> $r->note('disable_gzip').
Sometimes it seems like Igor does not really understand what he is speaking
about. No comments.
> 5. There are two unrelated mod_deflate. First is my mod_deflate for Apache
1.3:
> http://sysoev.ru/mod_deflate/
> It'd been tested for one year on loaded sites.
> Second is expiremental module for Apache2 by Apache tream.
I don't care about your personal affairs and associations. Please, keep it
in your personal records for future historical essays. This is a technical
tutorial.
Thanks,
Slava
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Igor Sysoev <is...@rambler-co.ru>.
On Wed, 12 Jun 2002, Slava Bizyayev wrote:
> Since now the draft tutorial "Features of Content Compression for Different
> Web Clients" (for Part IV: Client side facts and bugs) is available for
> preview and discussion at
> http://devl4.outlook.net/devdoc/Dynagzip/ContentCompressionClients.html .
Here is first part of criticism.
1. You should not mix proxies and browsers.
2. As I said you MS Proxy has not mask at all. "^1\.1 " is not a mask.
"^Squid/" is incorrect mask.
Here is example of Via header of HTTP/1.1 request that goes
though Squid, MS Proxy and Oops:
"1.1 proxy1.domain1.com:3128 (Squid/2.4.STABLE2), 1.0 PROXY2,
proxy3.domain3.com:3128 (Oops 1.5.22f1)"
3. Proxy masks will not help. About 70% of all proxied request are going
through Squid and about 15% are going through MS Proxy.
So much safe way is to disable proxy requests at all instead of tring
to look mask.
Besides I suspect that most proxies handle compressed content incorrectly.
I had checked only Squid, MS Proxy and Oops but there are many another
proxies. So I think you should disable gzip for all proxied request
or enable it for all proxied request if you do not care about old broswer.
mod_deflate by default disable it.
4. You should not unset "Accept-Encoding". Better way is to set
$r->note('disable_gzip').
5. There are two unrelated mod_deflate. First is my mod_deflate for Apache 1.3:
http://sysoev.ru/mod_deflate/
It'd been tested for one year on loaded sites.
Second is expiremental module for Apache2 by Apache tream.
Next part will be about browsers bugs.
Igor Sysoev
http://sysoev.ru
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Per Einar Ellefsen <pe...@skynet.be>.
At 00:04 13.06.2002, Slava Bizyayev wrote:
>From: "Stas Bekman" <st...@stason.org>
>Subject: Re: tutorials (was: Re: rfc Apache::Dynagzip)
>
>
> > Probably the best post it here first, so we can get it reviewed and
> > commented on before we add it to the docs.
>
>Since now the draft tutorial "Features of Content Compression for Different
>Web Clients" (for Part IV: Client side facts and bugs) is available for
>preview and discussion at
>http://devl4.outlook.net/devdoc/Dynagzip/ContentCompressionClients.html .
>
>I strongly hope to make it much better with your help prior to submit for
>publishing. Any comments will be highly appreciated.
Looks great Slava! Seems to integrate the needed info. I guess those who
know more about Gzip encoding can tell you more technically-wise, but as
far as the general look it seems ok to me.
--
Per Einar Ellefsen
per.einar@skynet.be
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Igor Sysoev <is...@rambler-co.ru>.
On Wed, 12 Jun 2002, Slava Bizyayev wrote:
> Since now the draft tutorial "Features of Content Compression for Different
> Web Clients" (for Part IV: Client side facts and bugs) is available for
> preview and discussion at
> http://devl4.outlook.net/devdoc/Dynagzip/ContentCompressionClients.html .
About browsers.
First we should not mention any browser that does not send 'Accept-Encoding'.
So remove Opera 3.5 from list.
Netscape 4.x
All NN 4.x does not understand chunked content. And they should not.
Chunked encoding is part of HTTP/1.1 and NN4.x support HTTP/1.0 only.
It's server bug if server sends chunked response to HTTP/1.0 request.
And your devl4.outlook.net has this bug (I suspect 1.3.24 mod_proxy).
So remove this bug from list.
Netscape 4.0-4.05 understand gzip and x-gzip. They did not
send 'Accept-Encoding'.
MSIE 4.x
Code
$r->header_in('Range') > 0
or
length($r->uri) > 253
is wrong.
1. Range. We should send full (and probaly gzipped) response
to MSIE 4.x if it asks byte-range and our response can be gzipped.
We should disable byte-range but not gzipping.
2. $r->uri > 253. Not only $r->uri but also $r->args, server name, port
and user name and password. In short - all without 'http://' prefix.
URI can be - http://name:password@host:port/uri?args.
So in mod_deflate I simply check r->unparsed_uri > 200
MSIE 6.0
I do not understand this:
A: Unfortunately, IE6 (and perhaps earlier versions?) appears
to have a bug with gzip over SSL where the first 2048
characters are not included in the HTML rendering of the page
when refresh is pressed. It only seems to happen on longish
pages, and not when the page is first loaded. In fact, sometimes
it doesn't happen at all. The only current solution is to put
a 2048 character comment at the start of your longish pages
of all spaces (which compresses pretty well, fortunately).
If "bug with first 2048 characters are NOT included in HTML rendering"
then why to put 2048 character comment ? Comments do not included
in rendering.
FlashPlayer 4.x-5.x
>Plug-in. Fails to decompress data received from the browser.
flash recieves all data from browser. But it can play gzipped swf
because all browsers (except NN 4.x for Windows) uncompressed them.
All flash players can not handle gzipped data received via loadVariables()
and XML.Load() (5.x).
You had mentioned Galeon and SkipStone but had not mentioned
Mozilla 0.9.1 and Netscape6.1b1 that have bug. Yes, this browsers
already old and rare but Galeon and Skipstone now include own version string.
It's much simply to translate from Russian my information than to try
to interpret it.
Igor Sysoev
http://sysoev.ru
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Slava Bizyayev <sb...@outlook.net>.
From: "Stas Bekman" <st...@stason.org>
Subject: Re: tutorials (was: Re: rfc Apache::Dynagzip)
> Probably the best post it here first, so we can get it reviewed and
> commented on before we add it to the docs.
Since now the draft tutorial "Features of Content Compression for Different
Web Clients" (for Part IV: Client side facts and bugs) is available for
preview and discussion at
http://devl4.outlook.net/devdoc/Dynagzip/ContentCompressionClients.html .
I strongly hope to make it much better with your help prior to submit for
publishing. Any comments will be highly appreciated.
Thanks in advance,
Slava
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Stas Bekman <st...@stason.org>.
Slava Bizyayev wrote:
> It's going to be something like "Features of Content Compression for
> Different Web Clients" for Part IV: Client side facts and bugs. We'll be
> able to discuss details next week.
Sounds great, looking forward to it.
Probably the best post it here first, so we can get it reviewed and
commented on before we add it to the docs.
__________________________________________________________________
Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Per Einar Ellefsen <pe...@skynet.be>.
At 03:37 06.06.2002, Slava Bizyayev wrote:
>It's going to be something like "Features of Content Compression for
>Different Web Clients" for Part IV: Client side facts and bugs. We'll be
>able to discuss details next week.
Ok, great Slava, thanks a lot!
--
Per Einar Ellefsen
per.einar@skynet.be
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Slava Bizyayev <sb...@outlook.net>.
It's going to be something like "Features of Content Compression for
Different Web Clients" for Part IV: Client side facts and bugs. We'll be
able to discuss details next week.
Thanks,
Slava
----- Original Message -----
From: "Stas Bekman" <st...@stason.org>
To: "Per Einar Ellefsen" <pe...@skynet.be>
Cc: "Valerio_Valdez Paolini" <pa...@students.cs.unibo.it>; "Slava
Bizyayev" <sb...@outlook.net>; "mod_perl Mailing List"
<mo...@perl.apache.org>
Sent: Wednesday, June 05, 2002 11:44 AM
Subject: tutorials (was: Re: rfc Apache::Dynagzip)
> Per Einar Ellefsen wrote:
> > At 15:36 05.06.2002, Valerio_Valdez Paolini wrote:
> >
> >> On Tue, 4 Jun 2002, Slava Bizyayev wrote:
> >>
> >> > I don't know should it be a kitchen of every system administrator, or
> >> > somebody could volunteer to serve the public web site about the
current
> >> > conditions of different web clients and recommended masks?.. I can't
> >> host it
> >> > on my devl4, because it is a development machine. That would be
> >> better to
> >> > find some stable place, like mod_perl, or apache project ;-).
> >>
> >> Can you provide a compatibility list? I think that the new mod_perl
site
> >> is looking for new articles, may be the first part of Apache::Dynagzip
> >> man page is a good candidate... You could add also known bugs and
> >> features. But I cannot decide what goes on mod_perl site :)
> >
> >
> > Just like I would have said it myself :-) We're clearly looking for
> > information, and I was especially watching this thread for possible
> > inclusion. We have a nice place to do this, it's in our "Browser bugs"
> > section. Depending on the size of the document, it might go there or in
> > its own doc. Anyway, we welcome any submissions. Format is standard Pod.
> > See
> >
http://cvs.apache.org/viewcvs.cgi/modperl-docs/admin/style.pod?rev=1.8&conte
nt-type=text/vnd.viewcvs-markup
> > for style information, but don't worry too much about that, we'll fix
> > that as we go.
>
> I just want to add some clarifications to Per Einar comment.
>
> Are we looking for not strictly mod_perl but closely related material,
> which matters to the majority of mod_perl programmers?
>
> The short answer:
>
> Tutorials -> yes
> manpages -> no
> articles -> take23.org
>
> The long answer:
>
> Tutorials cover some interesting topics using several implementations.
> Tutorials are pretty much static and don't require much maintenance. We
> heartly welcome these. The ongoing discission of MVC is a good example
> of a tutorial candidate, templating comparison and *generic* tips and
> tricks are other ones.
>
> Manpages, which aren't the core module are not very welcome at this
> moment, as they usually require high level of maintenance, and we have
> hardly resources to cope with perl.apache.org. So at least for now,
> manpages aren't welcome.
>
> If you have feature tutorials, either submit those to take23.org or any
> other online zine. perl.com is looking for such articles. so does
> apacheweek.com. probable there are others.
>
> The new perl.apache.org is not a dump place for docs. The more
> irrelevant stuff we throw there the less added value the site will have,
> the harder it'll be to find something and the whole idea of expanding
> docs will do more bad than good. So new tutorials are definitely
> welcome, but re-read the first para to see the definition of a good
> candidate and so the existing tutorials at:
> http://perl.apache.org/release/docs/tutorials/index.html
> before submitting your tutorial. If your idea of tutorial doesn't fit
> into perl.apache.org's tutorial's idea, we will gladly link to it.
>
> ---
>
> Now back to the topic. If you can submit to us known problems with
> browsers and solutions that would be great. But please don't submit the
> Apache::Dynagzip manpage.
>
> __________________________________________________________________
> Stas Bekman JAm_pH ------> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:stas@stason.org http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
>
>
Re: tutorials (was: Re: rfc Apache::Dynagzip)
Posted by Perrin Harkins <pe...@elem.com>.
Stas Bekman wrote:
> The ongoing discission of MVC is a good example
> of a tutorial candidate
Incidentally, I already wrote a fair amount on this subject in the
eToys-related tutorial:
http://perl.apache.org/release/docs/tutorials/scale_etoys/etoys.html#Code_Structure
There's a diagram, code examples, etc. I wasn't planning to write a
spearate MVC one because I've already said most of it there.
- Perrin