Jorge wrote:
On Fri, Feb 29, 2008 at 06:19:31PM +0000, place wrote:
Jorge wrote:
- This patch always uses the same boundary, but a different one REALLY should be used for every form submission. At the least, the string should be scrambled up somehow.
Yes, please finish that part.
Probably checking the boundary string against URL_DATA, with strstr is a good idea too.
Attached.
I'm not proud of this code, but special cases were getting in the way of attempts at cleanup.
Have you tried something like?:
</pseudocode>
Html_submit_form2() ... if (ENC_MULTIPART) { append every single "name" "value" pair into a Dstr do { make boundary } while (strstr(Dstr, boundary) || maxtries); } ... encode as usual.
</pseudocode>
If yes, why does it fail?
I hadn't looked at that specifically. Let's see... To avoid duplicating the big case statement, I'd want to make a char *Html_get_input_value(input) { switch (input->type) { ... } return value; } if (ENC_MULTIPART) { for (each input in the form) { value = Html_get_input_value(input); dStr_append(data, name); dStr_append(data, value); } ...boundary... etc. ... } But for a file input, it could have embedded nulls, so make Html_get_input_value() return a Dstr* instead. Okay. But for an image input, thanks to clickpos, I'd have to make it return a list of name/value pairs. Maybe that's not too bad, but it does put me in a bit of a "stupid HTML and its stupid special cases!" mood. Random thought: I wonder whether url->data gets eradicated after sending somehow, or if copies of it stick around in copies of the url on, I don't know, the nav stack or whatever. If there are copies floating around, that'll be no fun if they were each to contain a big file input in their data.
PS: I usually manually delete the CC of my replies to you, thinking that you'll get it from dillo-dev. Do you want the extra copy?
I know someone who, when cc:ed, tends to say "I read the list" :)