incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: standalone attachments and content-encoding header
Date Thu, 18 Mar 2010 01:07:16 GMT
On Wed, Mar 17, 2010 at 6:52 PM, Randall Leeds <randall.leeds@gmail.com> wrote:
> It seems like couch should probably store content-encoding as metadata
> on the attachment (like content-type) and pass these attachments
> straight to disk and serve them up with the appropriate
> content-encoding OR reject the original upload as unsupported.
>
> I agree that the current situation is wrong.

I think in the current situation we're wrong. But to fix the current
situation we either need to reject content-encodings we don't know
about or add the code to deal with them.

Whether the implementation goes on and stores attachments in the
encoding in which they were uploaded is an implementation detail.
Though, it could get interesting when someone stores a deflate
attachment and wants to retrieve it as gzip.

Either way, CouchDB not being able to server and identity encoded body
of an attachment seems like a very silly proposition.

Paul

> On Wed, Mar 17, 2010 at 15:49, John Merrells <john@merrells.com> wrote:
>>
>> On Mar 17, 2010, at 3:38 PM, Paul Davis wrote:
>>
>>> That's not how HTTP works though. For it to respond with a
>>> "Content-Encoding: deflate" header CouchDB would need to understand
>>> the deflate content type and you would have to specify an
>>> Accept-Encoding header that preferred deflate over everything else.
>>>
>>> Patching in deflate support is a-ok by me if someone wants to do that.
>>> But just echoing headers isn't a viable solution.
>>
>> Just as couch doesn't need to know about a content-type in order to
>> serve content of that type, it also doesn't need to know about its encoding,
>> if the content is already encoded in that way. If the UA asked for a different
>> encoding than that which the content was in, then sure that's a problem,
>> but that's not the case here.
>>
>> So the client sends....
>>
>> UA  ---> Couch
>> PUT /database/document_id/attachment_name
>> content-type: foo/baz
>> content-encoding: bar
>>
>> And so when the client asks for its blob back
>>
>> UA ---> Couch
>> GET /database/document_id/attachment_name
>> accept-encoding: bar
>>
>> We would expect...
>>
>> Couch <--- UA
>> content-type: foo/baz
>> content-encoding: bar
>>
>> But this is actually what is returned...
>>
>> Couch <--- UA
>> content-type: foo/baz
>>
>> So, it dropped the encoding, which is confusing for the client.
>>
>> John
>>
>> --
>> John Merrells
>> http://johnmerrells.com
>> +1.415.244.5808
>>
>>
>>
>>
>>
>>
>>
>

Mime
View raw message