W3C home > Mailing lists > Public > www-qa@w3.org > January 2003

Re: CUAP 3.1

From: Alex Rousskov <rousskov@measurement-factory.com>
Date: Tue, 28 Jan 2003 16:38:17 -0700 (MST)
To: Jim Ley <jim@jibbering.com>
cc: www-qa@w3.org
Message-ID: <Pine.BSF.4.44.0301281623100.68873-100000@measurement-factory.com>

On Tue, 28 Jan 2003, Jim Ley wrote:

> "Alex Rousskov" <rousskov@measurement-factory.com>
> > On Tue, 28 Jan 2003, Jim Ley wrote:
> > > A user is likely to be confused if they open a URI (say
> > > http://www.example.org/stuff.html ) with content-type: text/html and
> > > content-encoding: gzip, in their HTML UA, they then save it locally and they
> > > can no-longer use their HTML UA to open it.
> >
> > Two counter-arguments: First, a decent UA should be able to "open" a
> > compressed document, especially if it saved the document as such.
> I don't agree with this, how is it supposed to know it's compressed?

Same way it will know that it is "HTML".

The technique would depends on a local (operating system, etc.)
environment, of course.  For example, UA can look at the extension of
the saved file and have a configurable list that maps extensions to
content types/encodings. The point is that if UA saved a document as
compressed (without user intervention other than supplying file
"name"), then the same UA ought to be able to open it as compressed.
Specific actions that UA may take to mark a document as compressed are
out of CUAP scope (an extension map is a typical example though).

> Whilst what you say is undoubtedly true for HTTP, it's a completely
> useless, and suggests that content-encoding has basically no use on
> the web today,

The overall concept works fine with several UAs I use. Not sure why
you think it is completely useless.

> and transfer-encoding should be used, if this is so the document
> very much needs to be saying this, as content-encoding is the one
> that is used.

The problem with transfer-encodings is that they are hop-by-hop and
poorly supported. Transfer-encoding is just a transfer "optimization".
Content-encoding is resource (storage, management, rendering, etc.)

> > Second, and perhaps more important, an average user should not know
> > that the resource is "HTML". The resource should be named
> > http://www.example.org/stuff to avoid confusion.
> They still know it's a document they viewed in their web browser,
> then saved it, and now can no-longer open it, hiding the extension
> does nothing to solve this problem, which is the key one, the
> average user would also not have a gunzip available.

The user will not need gunzip. If UA was able to render and save
compressed document, the same UA should be able to open it (again).
The details of file naming and content encoding should be transparent
to an average user.

If UA knows that its current invocation environment does not allow for
more-or-less reliable way to mark stored content as compressed, that
UA may decode and store uncompressed. However, it does not solve the
problem you seem to be referring to. If there is no way for UA to
guess that the file contains compressed content (i.e., guess
content-encoding), then there is probably no way for UA to guess that
the file contains HTML either (i.e., guess content type)!


                            | HTTP performance - Web Polygraph benchmark
www.measurement-factory.com | HTTP compliance+ - Co-Advisor test suite
                            | all of the above - PolyBox appliance
Received on Tuesday, 28 January 2003 18:38:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:40:30 UTC