Ticket #73 (closed design: fixed)
Clarification of the term "deflate"
|Reported by:||email@example.com||Owned by:||firstname.lastname@example.org|
|Component:||p1-messaging||Severity:||Active WG Document|
Below is the definition of "deflate" from RFC 2616, section 3.5 "Content Codings"
deflate The "zlib" format defined in RFC 1950  in combination with the "deflate" compression mechanism described in RFC 1951 .
There is ambiguity in that definition because of the inconsistent use of the term "deflate". This has resulted in a long standing confusion about how to implement "deflate" encoding.
There was a time a few years back when most of the high profile browser and some http server implementations incorrectly implemented http "deflate" encoding using RFC 1951 without the RFC 1950 wrapper. Admittedly most, if not all, of the incorrect implementations have now been fixed, but the fix applied recognises the reality that there are incorrect implementations of "deflate" out in the wild. All browsers now seem to be able to cope with "deflate" in both its RFC1950 or RFC1951 incarnations.
So I suggest there are two issues that need to be addressed
- The definition of "deflate" needs to be rewritten to remove the ambiguity.
- Document the reality that there are incorrect implementations, and recommend that anyone writing a "deflate" decoder should cope with both forms.
- Component set to non-specific
- Milestone set to unassigned
- Component changed from non-specific to p3-payload
- Owner set to email@example.com
- Priority set to normal
- Severity set to Active WG Document
- Owner changed from firstname.lastname@example.org to email@example.com
- Status changed from new to assigned
- Component changed from p3-payload to p1-messaging
comment:10 Changed 5 years ago by firstname.lastname@example.org
- Status changed from assigned to closed
- Resolution set to incorporated
comment:11 Changed 5 years ago by email@example.com
- Status changed from closed to reopened
- Resolution incorporated deleted