archiva-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: MRM-1351: please advise
Date Tue, 02 Mar 2010 14:25:35 GMT

On 02/03/2010, at 8:15 PM, Marc Lustig wrote:

> brettporter wrote:
>> The main problem with this is that Wagon currently streams the upload, and
>> calculates the checksum as it goes, to upload as a separate file
>> afterwards (remembering that, I don't know why I thought the checksum went
>> first). Sending the checksum in a header would require reading a file
>> twice - not a big deal, but a fair change to the way it works right now.
>> It's not unreasonable, but it's probably not that necessary given that


> What came to my mind now is that instead of sending the checksum as an
> additional file, we could simply add the checksum as an HTTP header-entry to
> the DAV-request that sends the artifact.
> That way, the contract of the deploy-process will not be changed and we
> avoid compatibility issues with other repo-managers.
> Should the checksum be created on the fly, or should it be read from the
> local-repo?
> Should one of md5 or sha1 be sent or both checksums?

The checksum is not in the local repository after 'install'. It is created on the fly by Wagon
as I described above. The problem is, you are going to end up changing the way Wagon works
to do it, or calculating the checksum twice (once at the start and once on the fly), which
was the problem I mentioned above. It certainly isn't a huge problem, I just think it might
be best to address it purely on the server side.

> Regarding Archiva, only a minor change is needed. Instead of placing the
> file in the managed repo unverified, the checksum needs to be read from the
> HTTP-header and compared with a freshly generated checksum based on the file
> received. We will need to discuss the proper place to add the code.
> How sounds that plan for you?

It is a cleaner solution, but I'm a bit concerned about the size of the change on the client
side, and that the feature will only work with some clients and so not be very reliable.

I also don't think it will gain much over the content-length check - it is only going to discover
additional edge cases where they are the same size but the checksum is wrong, which would
be very unusual. It might help detect where a client flat-out gets the checksum wrong, but
that doesn't seem to be the main concern here.

It won't help with the Maven bugs where the client sends the wrong checksum after the fact,
getting back to your other message:

On 02/03/2010, at 9:54 PM, Marc Lustig wrote:

> I have looked into the deploy-plugin (trunk), apparently in
> DefaultWagonManager.putRemoteFile() method there is already some logic
> implemented to add SHA-1 and MD5 hashes using addTransferListener() -
> although I would not bet this logic is working at all until I have testet
> it.

I'm quite certain they work, with the exception of the problems in the issues I originally
pointed out where things get accidentally uploaded twice (and so the checksum is double-processed
and incorrect). In that case it's the uploading twice that is wrong, not the checksum calculation.
The solution above wouldn't help as you'd send the same (correct) header twice, but then the
wrong checksum file afterwards.

I am interested in getting to the bottom of your core problem though. Have you been able to
try the extra debugging I added to see if it logs the error causes?


Brett Porter

View raw message