You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modproxy-dev@apache.org by Eli Marmor <ma...@netmask.it> on 2001/11/11 09:30:40 UTC

Re: Charsets, Akamai, and Rock-n-Roll

On September 4, I wrote:

> Hi,
> 
> (...following later...)

Somewhere between September 4 and now, the second problem has been
disappeared *PROBABLY* (this seems OK from first look).

Currently, I use the CVS snapshot httpd-2.0_20011110210001, while the
version that HAD the problem was httpd-2.0+mod_proxy_20010901210000 +
apr_20010902042105 + apr-util_20010902042122 (*A LONG TIME AFTER THE
AKAMAI PROBLEM WAS REPORTED AS "RESOLVED" !!!*).

If anybody opened a bug report, it can be closed (probably...) (I'll
report later this week, after I'm sure that it's gone).

As to the first problem, nothing has been done; Anybody look at it?

> After having several problems with a site that I'm involved with, and that
> I tried to access through mod_proxy of 2.0, I looked for another site (more
> public) that has the same problems, and found http://www.ynet.co.il (don't
> try to read it, unless you know Hebrew ;-)
> 
> Now to the problems:
> 
> 1. The charset is different than the charset that is published by the
>    original site.
>    This is happenning because Apache RE-CREATES the "Content-Type" header,
>    with its OWN default charset, no matter what the real site chose.
>    I consider it a bug, and even without looking at any RFC, I'm sure it is
>    "not what the author intended".
>    We should not (re-)set such headers, even if they were empty (i.e. if we
>    have "Content-Type: text/html", with no
>                 "; charset="
>    after, we should pass it as-is).
> 
>    I worked around my SPECIFIC need by adding "AddDefaultCharset Off" (I
>    could also comment the original "AddDefaultCharset"), but a more generic
>    solution must be implemented.
> 
> 2. There are still problems with akamai. The page I mentioned, fails in
>    downloading 67 of its components. Many of them are akamai's, and the
>    others have probably the same cause of problem (the number - 67 - is so
>    high because the browser counts all the repeatitions).
> 
> General Details:
> ================
> 
> I use MSIE 5.0 under Windows 2000.
> 
> I compiled and ran the proxy under Solaris 8 with the latest GCC and libs
> from sunfreeware.com:
> 
> ./configure     \
>         --prefix=/usr/local/apache2     \
>         --enable-modules=most           \
>         --enable-shared=max             \
>         --enable-cache                  \
>         --enable-cache-filter           \
>         --enable-proxy                  \
>         --enable-proxy-connect          \
>         --enable-proxy-ftp              \
>         --enable-proxy-http             \
>         --enable-ssl=shared
> 
> The details of the site can be received by accessing it.

Thanks,
-- 
Eli Marmor
marmor@netmask.it
CTO, Founder
Netmask (El-Mar) Internet Technologies Ltd.
__________________________________________________________
Tel.:   +972-9-766-1020          8 Yad-Harutzim St.
Fax.:   +972-9-766-1314          P.O.B. 7004
Mobile: +972-50-23-7338          Kfar-Saba 44641, Israel

Re: Charsets, Akamai, and Rock-n-Roll

Posted by Eli Marmor <ma...@netmask.it>.
Graham Leggett wrote:
>
> Eli Marmor wrote:
> 
> > Somewhere between September 4 and now, the second problem has been
> > disappeared *PROBABLY* (this seems OK from first look).
> >
> > ...
>
> The Akamai problem was not reported as resolved, but rather as
> "no-fault-found" on Linux (and I think MacOS 10).
> 
> proxy relies heavily on the underlying filter subsystem, which has been
> extensively tested and fixed over the last few months. It's likely the
> Akamai problem was found and fixed outside the proxy code as a result of
> this testing.

Thanks.

I just want to clarify that I'm not sure that both bugs ("mine" and
Akamai's) are the same one; They just look similar (plus the fact that
about a half of the unreached URLs with "my" bug are stored at Akamai).

It seems that finally, after so many years of development, Apache 2.0
is starting to rock!
-- 
Eli Marmor
marmor@netmask.it
CTO, Founder
Netmask (El-Mar) Internet Technologies Ltd.
__________________________________________________________
Tel.:   +972-9-766-1020          8 Yad-Harutzim St.
Fax.:   +972-9-766-1314          P.O.B. 7004
Mobile: +972-50-23-7338          Kfar-Saba 44641, Israel

Re: Charsets, Akamai, and Rock-n-Roll

Posted by Chuck Murcko <ch...@topsail.org>.
On Sunday, November 11, 2001, at 04:39 , Graham Leggett wrote:

> Eli Marmor wrote:
>
>> Somewhere between September 4 and now, the second problem has been
>> disappeared *PROBABLY* (this seems OK from first look).
>>
>> Currently, I use the CVS snapshot httpd-2.0_20011110210001, while the
>> version that HAD the problem was httpd-2.0+mod_proxy_20010901210000 +
>> apr_20010902042105 + apr-util_20010902042122 (*A LONG TIME AFTER THE
>> AKAMAI PROBLEM WAS REPORTED AS "RESOLVED" !!!*).
>
> The Akamai problem was not reported as resolved, but rather as
> "no-fault-found" on Linux (and I think MacOS 10).
>
> proxy relies heavily on the underlying filter subsystem, which has been
> extensively tested and fixed over the last few months. It's likely the
> Akamai problem was found and fixed outside the proxy code as a result of
> this testing.
>

The problem indeed came and went several times (even after the date in 
proxy STATUS - that's why I put the date in). 8^) I also attribute this 
to work on the filters. Things got better after Graham merged the proxy 
back in to the core, and the 'akamai problem' was probably always 
related to the dechunk filter.

Chuck


Re: Charsets, Akamai, and Rock-n-Roll

Posted by Graham Leggett <mi...@sharp.fm>.
Eli Marmor wrote:

> Somewhere between September 4 and now, the second problem has been
> disappeared *PROBABLY* (this seems OK from first look).
> 
> Currently, I use the CVS snapshot httpd-2.0_20011110210001, while the
> version that HAD the problem was httpd-2.0+mod_proxy_20010901210000 +
> apr_20010902042105 + apr-util_20010902042122 (*A LONG TIME AFTER THE
> AKAMAI PROBLEM WAS REPORTED AS "RESOLVED" !!!*).

The Akamai problem was not reported as resolved, but rather as
"no-fault-found" on Linux (and I think MacOS 10).

proxy relies heavily on the underlying filter subsystem, which has been
extensively tested and fixed over the last few months. It's likely the
Akamai problem was found and fixed outside the proxy code as a result of
this testing.

Regards,
Graham
-- 
-----------------------------------------
minfrin@sharp.fm		"There's a moon
					over Bourbon Street
						tonight..."