Closed
Bug 68414
Opened 24 years ago
Closed 9 years ago
W3C CUAP: Allow the user to choose among supported transfer encodings
Categories
(Core :: Networking, defect, P5)
Core
Networking
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: gerv, Unassigned)
References
()
Details
[ 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.
Reporter | ||
Comment 1•24 years ago
|
||
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
Updated•24 years ago
|
Hardware: PC → All
Comment 2•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
Filed bug 68157 ([RFE] improved support for HTTP/1.1 transfer codings).
Depends on: 68157
Updated•23 years ago
|
Assignee: matt → neeti
Component: Preferences → Networking
QA Contact: sairuh → benc
Comment 6•23 years ago
|
||
-> Networking.
Comment 8•23 years ago
|
||
-> 1.0 perhaps (depends on when bug 68517 is fixed)
Severity: normal → minor
Status: NEW → ASSIGNED
Priority: -- → P5
Target Milestone: --- → mozilla1.0
Updated•22 years ago
|
Target Milestone: mozilla1.1alpha → ---
Updated•18 years ago
|
Assignee: darin → nobody
Status: ASSIGNED → NEW
QA Contact: benc → networking
Target Milestone: Future → ---
Updated•9 years ago
|
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•