18424 - nsHTTPHandler::NewPostDataStream should be a stream converter

Status: VERIFIED INVALID

(Core :: Networking, defect, P3)

Description

[Warren Harris]

Jud: We talked about this in our necko meeting today. NewPostDataStream makes
an instance of nsHTTPEncodeStream to convert CRLF conventions, etc. (I was
mistaken when I said this was a method on nsIOService.) This should be changed
to be a normal stream converter.

Note that unlike other stream converters, this one is used for data going out
to the server, as opposed to coming in. I hope that doesn't throw a wrench in
the architecture.

Comment 1

[leger]

Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Comment 2

[Judson Valeski]

out to server issue shouldn't matter. nsIStreamConverterService provides input 
stream conversion. How the stream is used doesn't matter.

Comment 3

[Warren Harris]

I'm not sure what you mean by that comment. My point is that when sending to a 
server, you may have an arbitrary mime type in hand that requires conversion 
before sending. Right now, we're hard-coding one converstion (or is it 2?) in 
nsHTTPEncodeStream -- it would be better if this was generalized to just invoke 
the stream converter stuff.

Comment 4

[Warren Harris]

Not needed for beta. M15. 

Comment 5

[Judson Valeski]

Ok, I've poked around with this a bit and here's what I've come up with. HTTP
provides some encode/post data stream creation apis. These provide an input
stream to the caller which does "encoding/conversion" in it's implementation.
The current usage is synchronous (nsIInputStream) based as opposed to
asynchronous (nsIStreamListener) based.

nsIStreamConverter provides both a synchronous api and an asynchronous api.
Wrapping the current nsHTTPEncodeStream implementatation with the
nsIStreamConverter api is easy, and current users will just use a different
stream retrieval mechanism (nsIStreamConverterService) to get their encoding
stream.

With that said, I need to build an asynchronous encoder to fill out the async
stream converter api impl.

The current retrieval mechanism used by nsIStreamConverterService is progid
based and has grown up around mime-to-mime type mapping conventions. For
example, I may want to go from text/plain to text/html. The encode stream stuff
breaks that convention as it's not mime conversion, rather it's an encoding. I
need to figure out how to fit this stuff into the stream converter service.
potts dropped some decoders in there, maybe I can follow that lead.

Comment 6

[Warren Harris]

Moving to M16.

Comment 7

[Gagan]

This should be happening inside HTTP. We are adding way too many must-do items
for someone to do a POST. Plus this is HTTP only. The async issues should go
away when I check in AsyncWrite stuff for HTTP. Maybe we just add something like
PostAsyncWrite that does all this stuff (including finding out the correct
Content-Length to use, using the right convertors, and finally calling
AsyncWrite with it)

Comment 8

[Judson Valeski]

well, I've basically done all the work to push it out as a stream converter. Do 
you want to use it as such *inside* HTTP?

Comment 9

[Gagan]

sounds fine to me... 

Comment 10

[Judson Valeski]

the only thing holding this back is a nsIFileInputStream name collision (gotta
love different interfaces with the same name).

Comment 11

[Judson Valeski]

->gagan

Comment 12

[benc]

mass move, v2.
qa to me.

Comment 13

[Darin Fisher]

this bug references code that was removed ages ago.  not much here is applicable
now.  marking INVALID.

Comment 14

[benc]

V/invalid.