HttpChannel should know its own content-disposition, so we can factor the code that's getting all over the tree. See bug 355332.

seems familiar to me, are you sure it's not a duplicate?

(In reply to comment #1) > seems familiar to me, are you sure it's not a duplicate? nope.

I don't think we have a separate bug on this. It came up in bug 224209, but that's all I can find.

(In reply to comment #1) > seems familiar to me Bug 299372 ?

Absolutely not.

renamed bug, as we want this for the JAR and Multipart channels as well, and to unify their interface. The current plan is to make them all inherit from nsPropertyBag, and store the disposition info there. This is already done for nsJARChannel (bug474536)--I'm going to implement for the other two. So far I've put just the raw header in ("attachment; filename=foo.jar"), but I may add logic to split the attachment and filename parts, and store them separately as "content-disposition" and "content-disposition-filename." Right now we're doing a lot of duplicate parsing of the raw header in various places, which is silly and probably error-prone. Cleaning up the various usage sites is also part of this bug.

Jason, you're not working on this anymore are you?

Kyle, No. The code is working, and refactoring it isn't even close to the top of my todo list.

Kyle, We're in the middle of trying to rip out the entire nsPropertyBag interface from channels (it doesn't work well with electrolysis), and we haven't figured out how that will look yet, so I'd recommend working on something else for now.

(In reply to comment #9) > Kyle, > > We're in the middle of trying to rip out the entire nsPropertyBag interface > from channels (it doesn't work well with electrolysis), and we haven't figured > out how that will look yet, so I'd recommend working on something else for now. Heh, ok. Guess I'll abandon this for now.

We'll fix this in 589292