Generally there is a cap to the amount of data that is allowed to be posted (via http) to a server. For example tomcat has maxSavePostSize (http://tomcat.apache.org/tomcat-5.5-doc/config/http.html)
Nz On Tue, Aug 2, 2011 at 12:49 PM, Dan Armbrust <daniel.armbrust.l...@gmail.com> wrote: > Well, this is interesting. > > A little background. > I have an admin account on the archiva server. The password is > "expired", but I don't want to change it. So I haven't changed it, > and I ignore the change requests. It still lets me use the GUI. As a > side note, Archiva really shouldn't be enforcing arbitrary password > policies, IMHO. Forced password changes are silly even in high > security places. And this isn't high security.... > > Anyway. When I was trying to use maven to upload before, it was > giving me a 401 error. I (correctly) assumed that it was doing this > because my password was expired. > > So I created a new account. I made it a "Repository-Manager". > > And then I tried uploading small files using this new account, and it > worked fine. > > However, when I try to upload a large file, I get the broken pipe at > an arbitrary point, and the server reports: > > myip - - [02/Aug/2011:17:02:27 +0000] "PUT > /archiva/repository/apelon-data//com/apelon/va/ihtsdo/wb/snomed/snomed-data/2010.07.31-build1-sct-en-vtmvmp-non-human-2-versioni-junk/snomed-data-2010.07.31-build1-sct-en-vtmvmp-non-human-2-versioni-junk.zip > HTTP/1.1" 401 0 "-" "Apache-Maven/2.2 (Java 1.6.0_25; Linux > 2.6.31-23-generic) maven-artifact/2.2.1" > > And also: > 2011-08-02 13:02:27,500 [btpool0-39] INFO > org.apache.maven.archiva.security.ArchivaServletAuthenticator - > Authorization Denied > [ip=myip,permission=archiva-upload-repository,repo=apelon-data] : no > matching permissions > > So, somewhere along the way when uploading a large file it would > appear Archiva gets confused and loses the credentials. > > Probably not related, but I have also noticed that the GUI upload > suffers from a design flaw with large uploads here too - when the > upload takes longer than the default session timeout, the session > times out before the upload completes. The upload will be processed > successfully - but the user doesn't know this - because the update > never comes back to the browser saying that it finished. In fact, the > browser stays stuck, waiting for the page to finish loading forever... > which leads me to suspect that you may have a socket leak on your end > when you expire a session while a request is still being processed. >
