squeakmap and EOCD Position

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

squeakmap and EOCD Position

NorbertHartl
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


Reply | Threaded
Open this post in threaded view
|

Re: squeakmap and EOCD Position

Karl-19
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
>
>
>
>  
Is it related to this bug report ?
http://bugs.squeak.org/view.php?id=5200

Karl

Reply | Threaded
Open this post in threaded view
|

Re: squeakmap and EOCD Position

Göran Krampe
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

Reply | Threaded
Open this post in threaded view
|

Re: squeakmap and EOCD Position

NorbertHartl

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


Reply | Threaded
Open this post in threaded view
|

Re: squeakmap and EOCD Position

Göran Krampe
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

Reply | Threaded
Open this post in threaded view
|

Re: squeakmap and EOCD Position

NorbertHartl

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.
>
Glorp was my first package released on squeakmap. Not knowing the UI
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