libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] MHD HTTPS IE vs. Firefox


From: Christian Grothoff
Subject: Re: [libmicrohttpd] MHD HTTPS IE vs. Firefox
Date: Tue, 26 Nov 2013 20:02:00 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

Dear Daniel,

Which version of libmicrohttpd did you do this to, and in which line?
In SVN HEAD, there is no "++(*ioffptr)", and if buffer_pos < 2 +blen,
the code doesn't increment ioffptr either (note that the respective
statement is was commented out some time ago.

There is one place left (line 560) where we increment *ioffptr by one,
but that's _after_ we've checked that buffer_pos >= 2+blen, and thus
1 != pp->buffer_pos should already hold.  There used to be an issue
in this function, which was fixed on Oct 30.  So please check with
SVN HEAD (see ChangeLog).

Please do let me know if this does not address your issue.


Happy hacking!

Christian



On 11/26/13 13:48, Daniel Wunderlich wrote:
> Daniel Wunderlich <address@hidden> writes:
> 
>>
>> Hi,
>>
>> I made the experience, that my MDH behaves totally different between 
>> processing a HTTPS POST request from IE 9.0 or Firefox ESR 24.0
>> The IE request seems to be that way different, that my own PP_handler is 
>> not called. I think that there is an error in parsing the multipart/form-
>> data.
>>
>> MHD_Version: 0.9.31, but the behavior is the same with previous versions 
>> too.
>>
> 
> Hi Christian,
> 
> I added the following if-statement in the postprocessor.c find_boundary()-
> function:
> 
>       /* do not increase ioffptr if single '-' was received */
>       if ((0 != memcmp("-", buf, 1)) || (pp->buffer_pos!=1))
>         ++(*ioffptr);
> 
> As result of this modification the buffer memmove() at the end of 
> post_process_multipart() while loop (AGAIN mark) will not override a 
> single received dash (behavior of my IE with HTTPS).
> 
> Please check, if this really is a bug.
> 
> Kind regards, Daniel
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]