Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.220.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=wyzT2FnjHiyZfjnlc+dMArXltfvKd+EkkfLbP9vbNjgKe+TlOorfXy5JIBQ9LXagJW
         lndRXui0GxR8UVUd96v3XwshHfzPY5gMi3L8Sg324TK92y1Cj9T9YfwhxGsCjNdUvtiR
         wzVGeqqC0dVmwJAZrTGqXdxRlF1M6OvN190l4=
MIME-Version: 1.0
In-Reply-To: <BANLkTimdc04HK4sCeV7PWL+AjRk=BL2=Mw@mail.gmail.com>
References: <BANLkTik9qr8ZvAKe6HNz7O9csQHrE+wtdw@mail.gmail.com>
 <BANLkTimdc04HK4sCeV7PWL+AjRk=BL2=Mw@mail.gmail.com>
From: Paul Davis <paul.joseph.davis@gmail.com>
Date: Thu, 23 Jun 2011 13:54:36 +0000
Message-ID: <BANLkTikvnP03EOLiWQQS+YAaJZLWEtiGMQ@mail.gmail.com>
Subject: Re: attachments.js bug on Chrome
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1

I'm not entirely certain if the bug is in Chrome or how we expect
Chrome to react. I know there are browser differences when running
against localhost but I'm not entirely certain what they are and why.
I'll write a small test case in Python to try and reproduce and if so
will call it a Chrome bug and kick it to their issue tracker.

On Thu, Jun 23, 2011 at 5:02 AM, Randall Leeds <randall.leeds@gmail.com> wrote:
> Does this affect anything serious or just a contrived example? Is it a
> zero-length attachment or something, in the test?
>
> File it on the chromium issues and call a vote for 1.0.3 :)
> On Jun 22, 2011 5:58 PM, "Paul Davis" <paul.joseph.davis@gmail.com> wrote:
>> While preparing the 1.0.3 release I stumbled across an awesome bug in
>> the attachments.js test. Apparently Chrome will set the Content-Type
>> to null if the Content-Length is 0 and the response is served from
>> 127.0.0.1. I can reproduce this easily by just changing between
>> 127.0.0.1 and my local external IP 192.168.10.x in the URL bar and run
>> the test on both. Fails on 127.0.0.1 and not on the external IP. This
>> appears to be consistent on all branches.
>>
>> I have no idea what the best fix is here. Suggestions welcome.
>