Hi,
I have a strange thing trying to load the Glorp package via squeakmap. If I try to load the package I get the "Can't find EOCD Position" which is correct as the data which is returned contains an html page with the login form from squeakmap. If I go to the squeakmap entry and to the version and click on the URL of this entry I get a window with binary data. I assume this is the sar file. Does anybody have an idea why the install action in squeakmap triggers the login form while downloading from the URL works just perfect? Norbert |
Norbert Hartl wrote:
> Hi, > > I have a strange thing trying to load the Glorp package > via squeakmap. If I try to load the package I get the > "Can't find EOCD Position" which is correct as the > data which is returned contains an html page with the > login form from squeakmap. If I go to the squeakmap > entry and to the version and click on the URL of this > entry I get a window with binary data. I assume this is > the sar file. > > Does anybody have an idea why the install action in > squeakmap triggers the login form while downloading > from the URL works just perfect? > > Norbert > > > > http://bugs.squeak.org/view.php?id=5200 Karl |
Hi!
This has been fixed by me - it was the old SHA1 checksum issue again. This can be seen in the transcript btw. regards, Göran |
On Thu, 2008-01-10 at 01:03 +0200, [hidden email] wrote: > Hi! > > This has been fixed by me - it was the old SHA1 checksum issue again. > This can be seen in the transcript btw. > Good hint :) What is calculated into the SHA1? I only changed the URL for the package not touching the file itself. So how could there be a old hash? thanks, Norbert |
Hi!
Norbert Hartl <[hidden email]> wrote: > > On Thu, 2008-01-10 at 01:03 +0200, [hidden email] wrote: > > Hi! > > > > This has been fixed by me - it was the old SHA1 checksum issue again. > > This can be seen in the transcript btw. > > > Good hint :) What is calculated into the SHA1? I only changed the > URL for the package not touching the file itself. So how could > there be a old hash? The SHA1 checksum is on the contents of the file only. It is calculated when the URL changes and thus - if you upload a new file with the same name it will give us trouble. I need to do something smart about this. But your situation sounds different - for some reason when the server downloaded the file into its cache (when you changed the URL in the new release (or registered the new release) IIRC) - it appears to have gotten the HTML file instead. Not sure exactly why. regards, Göran PS. For those unaware - SM has a server side cache of all registered URLs - so that it can still server releases when original URL is for some reason not reachable. This is decided on a SHA checksum verification. The cached file can be reached using URLs of this kind: http://map.squeak.org/packagebyname/GLORP/autoversion/5/cache |
On Thu, 2008-01-10 at 12:50 +0200, [hidden email] wrote: > Hi! > > Norbert Hartl <[hidden email]> wrote: > > > > On Thu, 2008-01-10 at 01:03 +0200, [hidden email] wrote: > > > Hi! > > > > > > This has been fixed by me - it was the old SHA1 checksum issue again. > > > This can be seen in the transcript btw. > > > > > Good hint :) What is calculated into the SHA1? I only changed the > > URL for the package not touching the file itself. So how could > > there be a old hash? > > The SHA1 checksum is on the contents of the file only. It is calculated > when the URL changes and thus - if you upload a new file with the same > name it will give us trouble. I need to do something smart about this. > very well I copied the URL of the file manually. Unfortunately it was the URL for my account /account/files/... which is only valid if I'm logged in. Another user noticed me about trouble downloading the Glorp package. Then(!) I noticed the pull down to select uploaded files. So the file was never touched I just changed the URL for the file. So it is just to different URLs pointing to the same file. > But your situation sounds different - for some reason when the server > downloaded the file into its cache (when you changed the URL in the new > release (or registered the new release) IIRC) - it appears to have > gotten the HTML file instead. Not sure exactly why. > regards, Gran > > PS. For those unaware - SM has a server side cache of all registered > URLs - so that it can still server releases when original URL is for > some reason not reachable. This is decided on a SHA checksum > verification. The cached file can be reached using URLs of this kind: > The behaviour I get would be that if the old URL is cached and somehow used. I don't know how because in the downloaded map it still seems rigth. Norbert |
Free forum by Nabble | Edit this page |