Community
Participate
Working Groups
Created attachment 129515 [details] a patch to illustrate where the problem is I have uploaded an update site to tigris.org http server[1]. When I try to load the repository in Eclipse, it says that it cannot find repository at this address. However, when using the Test Connection button from the Available Software Sites preference page, everything is OK. After some investigation, the problem turns out to be inproper response to HEAD request, sent to the HTTP server. The Apache server responds without specifying Last-Modified header and Content-Length header. Although the response code is OK 200, p2 interprets this as missing file. I suppose that Test Connection button uses GET request, which tigris.org correctly respond to. It is questionable, where exactly is the problem. According to the HTTP specification, the response to HEAD request must be absolutely the same as the response to GET request, so tigris.org's Apache doesn't obey the specification. On other hand, p2 & ecf shouldn't treat this response as a missing file, only as a file without known last modified timestamp. I'm attaching a patch for p2 & ecf to fix this problem. I don't know much of the internal workings of p2 and ecf, so this patch illustrates the problem rather than fix it.
I forgot to point out the update site location: http://mtoolkit.tigris.org/updates/development
We fixed something similar to that recently (in M6). Which build do you see this problem on?
I first reproduced it on 3.5M6, but it happens on HEAD too. The patch is created against HEAD.
Pascal, I think you are referring to the change that a newer index file was not always recognized (i.e. xml vs. jar). That fix would have no effect on this problem. The problem here is that there is no difference in the code between "file not found" and lastmodified == 0. With the fix in bug 216278 is in - this is trivial to change, as proper exceptions are thrown for "FileNotFound". Some additional change is required though to treat lastmodified == 0 as very old. To make the implementation more resilient, it could make a new call using GET to get the header in this special case. I can add that once bug 216278 is release to HEAD.
Created attachment 130291 [details] Fix for this issue and additional issue - see comments The attached patch fixes the issue when a returned last modified == 0 due to server not handling HEAD correctly. The old code handled this as a "FileNotFound" - the new code handles a returned 0 as the cache is stale. Patch also fixes an additional problem where cache did not check for timestamp on cached file.
Henrik, the ECF API states that -1 is returned in case of error (IRemoteFileInfo#NONE), but you seem to only be checking for lastModifiedRemote == 0. All of these should be checking <= 0 in case ECF some day implements its spec correctly.
I have entered bug 270516 against ECF for the bug on their side (returning 0 rather than the specified value of -1 for failure). I think we should treat both 0 and -1 the same in order to avoid being broken by a fix on the ECF side.
Created attachment 130304 [details] Fix v03
Released my fix to HEAD.
The log messages should have the text "<= 0" as well. In my patch I also added checks for <= 0 to the checking of stale. The version you checked in only checks against 0. This would mean that if a protocol returns -1 because it is not possible to compute last modified, will cause the cache to never be updated. If the code got that far without a FileNotFoundException or any other error, then I think the correct behaviour is to treat the missing "last modfied" as if the index file is stale. Do you want a modified patch?
> Do you want a modified patch? Sure, a patch against latest in HEAD would be best.
Created attachment 130313 [details] patch to fix issue with -1 not treated as stale Patch fixes issue with -1 return from lastModified not being treated as stale.
Comment on attachment 130313 [details] patch to fix issue with -1 not treated as stale Thanks Henrik, released to HEAD.
Hello Henrik, Is there a solution in case the HTTP HEAD method is disallowed on the web server due to security and the server returns not found/404? We have such case and the update fails (although "Test connection" works). Kind Regards, Dinko
(In reply to comment #14) > Hello Henrik, > Is there a solution in case the HTTP HEAD method is disallowed on the web > server due to security and the server returns not found/404? > We have such case and the update fails (although "Test connection" works). > > Kind Regards, > Dinko I don't think we can handle a server that isn't implementing the HTTP spec. If a HEAD request returns 404 then it is valid to assume GET on the same URL will also be 404. In this bug, the server was returning different headers which is allowed by the spec. I suggest taking that up with whoever wrote/configured that server. HEAD is essentially GET except the response contains no body - from a security perspective they are equivalent. http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4
