11772 - nsFormSubmission needs to be cleaned up and use Necko

Status: RESOLVED WONTFIX

(Core :: Networking, defect, P3)

Description

[Warren Harris]

My understanding is that there is form post data encoding stuff going on in
nsFormFrame.cpp that probably should be pulled out and isolated as a general
necko stream filter.

We do something similar thing when encoding CRLF conventions when
posting/putting data or files. Check out
netwerk/protocol/http/src/nsHTTPEncodeStream.cpp to see how we did this. Chris:
If you can help us isolate the encoding stuff, we can put it in the appropriate
place in necko.

Cc'ing Rick Potts who pointed this out to me, and Chris Mcafee who did a lot of
the posting work for us.

Comment 1

[karnaze (gone)]

layout/html/forms/src/nsFormFrame::URLEncode(char* aInString, char* aOutString)
originally did the encoding for non unicode strings. I think Frank added another
signature for unicode. I'm not sure if both are being used or just the unicode
version. I'm also not sure if ProcessAsMultipart() belongs in Necko.

There is other crude in nsFormFrame which should be replaced including
GetFileNameWithinPath(), Temp_GetTempDir(), Temp_GenerateTempFileName, and
Temp_GetContentType().

Warren, if you are signing up for this work, much appreciation. If not, please
reassign to Eric Pollmann. However, he may not be able to get to it for a while.

Comment 2

[Warren Harris]

Chris, Thanks for the info. I'll take it from here.

Comment 3

[Frank Tang]

I am not sure what you want to do. What I did is the following-
1. We have Unicode string as name/value of form elements.
2. We have to convert them back to a non Unicode bytes
3. After that, we URL-encoded for ENCTYPE of url-encoded. We don't do this for
multipart
4. Therefore, my code is perform charset conversion in 2 instead of using the
broken ToNewCString code (which is a good hack for ASCII and for
prototype purpose, but not good for real usage.). In order to do that, I need to
find out the charset of the origional document, or (this is not implement yet)
check the Accept-Charset attribute (not the Accept-Charset HTTP header) in the
html FORM tag. )
5. We label the charset as an attribute and attached in the end of the submitted
"Content-Type:" header.

If you want to move this code to somewhere else, make sure you pass the
necessary information (the charset of the document, or the Accept-Charset
attribute of the form) as the parameter (or accessable from the new code).

Please let me know if you want to move it. Also let me know after you move it
since there are one more thing I need to do for the multipart. See bug 5313 for
details.)

Comment 4

[leger]

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

component.

Comment 5

[Warren Harris]

Moving non-essential, non-beta2 and performance-related bugs to M17.

Comment 6

[Paul MacQuiddy]

spam, changing qa contact from paulmac to [e-mail] on networking/RDF 
bugs

Comment 7

[Warren Harris]

Giving this to Gagan now.

Comment 8

[Gagan]

eric wants to have a peek at this... 

Comment 9

[Eric Pollmann]

This does not affect correctness, stability, footprint, or performance - moving
of to Future!  :)

Comment 10

[benc]

mass move, v2.
qa to me.

Comment 11

[benc]

based on the assignie, I'm wondering if this belongs in the networking component...

Comment 12

[Eric Pollmann]

Some work does need to be done in Necko too.  CC'ing Gagan.  This will not
happen anytime soon though - correctness, crash, and dataloss bugs need fixed first.

Comment 13

[Kevin McCluskey (gone)]

Bulk reassigning Eric Pollmann's remaining form submission bugs to Alex.

Comment 14

[John Keiser (jkeiser)]

Multipart data is going to be almost impossible to encode using a stream; but
url-encoded POST data might.  Would a URLEncoding stream be useful to anyone
else?  I'm not entirely convinced this is worth it.

See bug 120682, where we have added a couple of streams and cleaned up
submission; none of these streams is a filter, however.