What prompted this bug was bug 162171. Basically, stream converters can affect various properties of the channel, like content type, content length, etc. They can reset content type with no trouble, but many channel impls (HTTP in particular) don't allow setting content-length. Darin isn't happy with the idea of allowing anyone to set the content-length of an HTTP channel, so we need to think of a good way to do this whole stream converter thing...
16 years ago
unfortunately, however, allowing stream converters to call SetContentLength may be the easiest solution... not that it doesn't make me nervous ;-)
Note that stream converters may not know the 'final' length. Stuff like the directory listing stream converter is one example, but I don't know if all the compressoin algorithms allow this, even if we know the input size. And then, of course, chunked encoding doesn't have a known content type until we finish the decoding entirely...
Isn't that what content-length = -1 and application/x-unknown-content-type are for?
good point. (btw: chunked decoding happens within the http code on the socket thread)
Status: NEW → ASSIGNED
Target Milestone: --- → Future
-> default owner
Assignee: darin → nobody
Status: ASSIGNED → NEW
QA Contact: benc → networking
Target Milestone: Future → ---
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.