Last Comment Bug 68414 - W3C CUAP: Allow the user to choose among supported transfer encodings
: W3C CUAP: Allow the user to choose among supported transfer encodings
Status: RESOLVED WONTFIX
:
Product: Core
Classification: Components
Component: Networking (show other bugs)
: Trunk
: All All
: P5 minor with 2 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
http://www.w3.org/TR/2001/NOTE-cuap-2...
Depends on: 68517
Blocks: 68427
  Show dependency treegraph
 
Reported: 2001-02-10 01:31 PST by Gervase Markham [:gerv]
Modified: 2015-12-11 11:42 PST (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Gervase Markham [:gerv] 2001-02-10 01:31:23 PST
[ This bug is one of the recommendations in the W3C's "Common User Agent 
Problems" document, URL above. One bug has been filed on each recommendation, 
for deciding whether we do it and, if not, whether we should. ]

1.12 Allow the user to choose among supported transfer encodings.

     HTTP/1.1 [RFC2616] allows transfer encoding. An example of encoding is
     data compression, which speeds up Web browsing over a slow connection.

     The user agent should allow the user to set the transfer encoding in
     the HTTP requests sent out.
Comment 1 Gervase Markham [:gerv] 2001-02-10 01:55:30 PST
We have UI for this, but it's in the Debug prefs. If it's official UI, then we 
need to move it out of there.

Gerv
Comment 2 Jesse Ruderman 2001-02-10 13:35:01 PST
This sounds like something that should be a debugging pref (if it's a pref at 
all).  Why would a user want to switch to a different transfer encoding?
Comment 3 Andreas M. "Clarence" Schneider 2001-02-10 19:32:44 PST
HTTP/1.1 makes a difference between *transfer* encoding and *content* encoding.

If I read the W3C-CUAP literally it says: When making a request which contains
an entity (i.e. a POST), use a user-defined transfer encoding. This would
probably confuse any HTTP/1.0 server and even HTTP/1.1 servers are likely to
respond with 501 (Not Implemented).

Probably they meant "allow the user to set the transfer encoding*s* they are
willing to *accept*". That means: Set a *TE* header to whatever the user wishes.

AIUI, what we have in the Debug prefs is a customization of the
*Accept-Encoding* header, which affects *content* encoding.

Why users might want to specify *content* encodings: When they save a document,
the *content* encoding IMO should be preserved (Moz does not, see bug 35956;
W3C-CUAP assumes that in 3.1 (see bug 68420)), cause it is a property of the
retrieved entity.

The only reason I can imagine why users might want to edit TE headers is, when
they are used to request encrypted data. But I do not know if such an encryption
standard exists (RFC 2616 does not define one).
IMO, TE should always be set to accept all compression formats Moz supports
(maybe there are problems with existing servers or with transfer encodings in
Moz itself, don't know).

Relevant parts in RFC 2616 (HTTP/1.1):
 3.5  Content Codings
 3.6  Transfer Codings
14.3  Accept-Encoding
14.11 Content-Encoding
14.39 TE
14.41 Transfer-Encoding
Comment 4 Andreas M. "Clarence" Schneider 2001-02-11 12:55:46 PST
Filed bug 68157 ([RFE] improved support for HTTP/1.1 transfer codings).
Comment 5 Andreas M. "Clarence" Schneider 2001-02-11 13:02:26 PST
Meant bug 68517.
Comment 6 Samir Gehani 2001-09-13 14:58:54 PDT
-> Networking.
Comment 7 neeti 2002-01-14 09:46:37 PST
darin: can you prioritize this.
Comment 8 Darin Fisher 2002-01-14 15:21:23 PST
-> 1.0 perhaps (depends on when bug 68517 is fixed)
Comment 9 Darin Fisher 2002-03-01 15:14:23 PST
-> moz 1.1
Comment 10 Darin Fisher 2002-05-17 16:25:00 PDT
mass futuring of untargeted bugs

Note You need to log in before you can comment on or make changes to this bug.