figure out how stream converters should be exposed

NEW
Unassigned

Status

()

Core
Networking
P5
normal
16 years ago
9 months ago

People

(Reporter: bz, Unassigned)

Tracking

(Blocks: 1 bug, {arch})

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-would-take])

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...

Comment 1

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?

Comment 4

16 years ago
good point.  (btw: chunked decoding happens within the http code on the socket
thread)

Updated

16 years ago
Status: NEW → ASSIGNED
Keywords: arch
Target Milestone: --- → Future

Comment 5

12 years ago
-> default owner
Assignee: darin → nobody
Status: ASSIGNED → NEW
QA Contact: benc → networking
Target Milestone: Future → ---
Whiteboard: [necko-would-take]
You need to log in before you can comment on or make changes to this bug.