incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keith Gable <zi...@ignition-project.com>
Subject Re: Storing text/plain attachments and digest
Date Sat, 03 Nov 2012 20:12:28 GMT
Another option would be to send the files as application/octet-stream. I
don't think those are compressed.


---
Keith Gable
A+ Certified Professional
Network+ Certified Professional
Storage+ Certified Professional
Mobile Application Developer / Web Developer



On Thu, Nov 1, 2012 at 9:09 PM, Mclean, Adam <adam.mclean@rbc.com> wrote:

> Of course! Makes perfect sense considering the compression.  Adding my
> own property to the document sounds like the winner then.
>
> Thanks for the direction.
>
> -----Original Message-----
> From: Robert Newson [mailto:rnewson@apache.org]
> Sent: 2012, November, 01 8:18 PM
> To: user@couchdb.apache.org
> Subject: Re: Storing text/plain attachments and digest
>
> To be specific, the Content-MD5 is always the MD5 of the response body,
> but this is not necessarily true for ETag. If you do want it to match,
> then either use a content-type that is not going to be compressed, or
> remove the content-type from couchdb's configuration.
>
> It is appropriate (w.r.t RFC 2616) to depend on the Content-MD5 header.
> If you supply when when PUT'ting a standalone attachment, we'll even
> verify it matches and return an error if it doesn't.
>
> Jens, I'm not familiar with that optimization but, if it exists, it came
> after I exposed the MD5 in this manner. The only place I think the
> replicator is involved is that, by emitting this information, the
> replicator validates that attachments aren't corrupted in transit.
>
>
> On 2 November 2012 00:05, Jens Alfke <jens@couchbase.com> wrote:
>
> >
> > On Nov 1, 2012, at 1:49 PM, "Mclean, Adam" <adam.mclean@rbc.com>
> wrote:
> >
> > > The digest produced by the file upload is key to this working for me
>
> > > so I'm not replacing files that are already the same in couch.  I've
>
> > > been
> >
> > IMHO you should not try to interpret the contents of the attachment
> > 'digest' property. It's mostly meant as an optimization for the
> > replicator, not as a user feature. Don't assume that it consists of
> > the string "md5-" followed by a hex MD5 digest of the actual
> > attachment contents. As you've seen, this isn't true for compressed
> > attachments. It's even more untrue for attachments on TouchDB, which
> uses a SHA1 digest instead.
> >
> > If you need to track the identities of attachments using a digest, it
> > would be safer to add your own digest property to the document, so
> > that you have control over how it's generated.
> >
> > -Jens
> _______________________________________________________________________
>
> This email may be privileged and/or confidential, and the
> sender does not waive any related rights and obligations.
> Any distribution, use or copying of this email or the
> information it contains by other than an intended recipient
> is unauthorized. If you received this email in error,
> please advise the sender (by return email or otherwise)
> immediately. You have consented to receive the attached
> electronically at the above-noted email address; please retain a
> copy of this confirmation for future reference.
>
> Ce courriel est confidentiel et protégé. L'expéditeur ne renonce
> pas aux droits et obligations qui s'y rapportent. Toute diffusion,
> utilisation ou copie de ce courriel ou des renseignements qu'il
> contient par une personne autre que le (les) destinataire(s)
> désigné(s) est interdite. Si vous recevez ce courriel par erreur,
> veuillez en aviser l'expéditeur immédiatement, par retour de courriel
> ou par un autre moyen. Vous avez accepté de recevoir le(s) document(s)
> ci-joint(s) par voie électronique à l'adresse courriel indiquée ci-dessus;
> veuillez conserver une copie de cette confirmation pour les fins de
> reference future.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message