• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: multipart upload become garbage
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: multipart upload become garbage


  • Subject: Re: multipart upload become garbage
  • From: Yung-Luen Lan <email@hidden>
  • Date: Fri, 7 Jan 2011 18:51:27 +0800

I did some tests and verified that the string and multipart binary
POST is correct.

What I did to fix the bug is just removing 8 lines of erroneous code
which attempt to add a zero to the end of the content.

https://github.com/yllan/wonder/commit/175145c3897f7da92be66d7be07802fb5f0dd461

     if (req->content) {
        content_buffer = (char *)WOMALLOC(req->content_length+1);
        strncpy(content_buffer,req->content,req->content_length);
        content_buffer[req->content_length] = '\0';
        WOLog(WO_INFO, "---content buffer: %s",content_buffer);
        strncpy(req->content,content_buffer,req->content_length+1);
        WOFREE(content_buffer);
     }

The removed code is wrong because:

1. The size of req->content (a byte array) is
req->content_buffer_size, not necessary req->content_length.

if (req->content_buffer_size < req->content_length &&
memset(req->content, 0xFF, req->content_buffer_length))
    the_code_will_crash();

2. Even if (req->content_buffer_size == req->content_length), if
req->content didn't contains byte zero, it will crash since the second
strncpy will violate the memory access by one byte.

3. If there is byte 0x00 in req->content, the rest bytes will be
filled with 0x00 by strncpy().

Hence I believed it's safe to removed without affecting other logic.
(CGI Adaptor has almost symmetric structure with fcgi adaptor except
without this part).
But I don't use the adaptor in my production environment because I
realized that very few people actually use this and it's not been well
tested.
Maybe we could do a survey to see which http server/adaptor you use? I
guess apache2 dominates.

Wow, 8 lines of code worth a lot of explanation.

Regards,
yllan

On Fri, Jan 7, 2011 at 6:51 AM, Q <email@hidden> wrote:
> On 07/01/2011, at 2:27 AM, Yung-Luen Lan wrote:
>
>> It's been a while that I'm too busy to dig into this problem.
>>
>> Anyway, I found the WebObjects FastCGI adaptor is buggy when you want
>> to upload binary files using form because the code use strncpy() to
>> copy the contents from HTTP request. It stop copy when a 0x00 byte
>> occur.
>>
>> I was a bit surprise that few one complains about this (according to
>> quick search on google) since it's a severe defect that cause data
>> loss.
>> I wonder if people is still using WO fcgi adaptor. Nevertheless, I
>> have a patched version:
>>
>> https://github.com/yllan/wonder
>>
>> In case anyone still use the fcgi adaptor.
>
> Can you confirm your fix creates no other issues?
> Have you used this change in production for long?
>
> I will commit the change to wonder if that's all that is required to resolve the issue.
 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

References: 
 >Re: multipart upload become garbage (From: Yung-Luen Lan <email@hidden>)
 >Re: multipart upload become garbage (From: Q <email@hidden>)

  • Prev by Date: Re: multipart upload become garbage
  • Next by Date: DB Localization problem - valueForKey(): lookup of unknown key: 'my_desc'.
  • Previous by thread: Re: multipart upload become garbage
  • Next by thread: DB Localization problem - valueForKey(): lookup of unknown key: 'my_desc'.
  • Index(es):
    • Date
    • Thread