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? Thanks, Brett -- Brett Porter [email protected] http://brettporter.wordpress.com/
