In <news:[email protected]>, "Paul B. Gallagher" <[email protected]> wrote:
> »Q« wrote: > > In <news:[email protected]>, > > "Paul B. Gallagher" <[email protected]> wrote: > > > >> »Q« wrote: > >>> In <news:[email protected]>, > >>> "Paul B. Gallagher" <[email protected]> wrote: > >>> > >>>> When trying to view stories at nydailynews.com, I often get this > >>>> error message: > >>>> > >>>> Content Encoding Error > >>>> > >>>> The page you are trying to view cannot be shown because it uses > >>>> an invalid or unsupported form of compression. > >>>> > >>>> The page you are trying to view cannot be shown because it uses > >>>> an invalid or unsupported form of compression. > >>>> > >>>> Please contact the website owners to inform them of this > >>>> problem. > >>>> > >>>> [Try again] > >>>> > >>>> [end quote] > >>>> > >>>> What's up with that? IE never has any problem displaying the > >>>> pages, but SM won't even show me the source code. > >>>> > >>>> Here's an example, but pretty much any story from the "Editor's > >>>> Picks" rubric on the right side of their pages does this: > >>>> > >>>> <http://www.nydailynews.com/opinion/drug-testing-welfare-recipients-big-mistake-conservatives-article-1.1734098> > >>> > >>> gzip compression is what's being used, but that's been standard on > >>> the web for many years, and SM supports it fine. > >>> > >>> My only guess is that what you're getting is being mangled by a > >>> transparent proxy between you and the server. Using shift+reload > >>> *might* get around it. > >> > >> It does, wonder why. Can you explain? > > > > Access providers may cache pages, so users get their cached pages > > instead of getting them from the originating web server. This saves > > the provider some bandwidth. There's nothing in your settings that > > will change things. > > > > shift+reload sends your http request along with a header that > > indicates you want any caches to be bypassed, so the page you get > > should come from the originating server. > > Ahhh... > > And in this case the originating server isn't using the problematic > compression that SM supports? The originating server isn't doing anything problematic. My guess is the cache's copy of the pages were corrupted, and that SM thought a compression problem was causing it to see garbage, but I don't know. It seems unlikely the proxy is using any weird compression. _______________________________________________ support-seamonkey mailing list [email protected] https://lists.mozilla.org/listinfo/support-seamonkey
