the URL dance for http://www.swa.hpi.uni-potsdam.de/seaside/tutorial

Have you seen http://www.swa.hpi.uni-potsdam.de/seaside/tutorial lately?
Every page link goes through about 8 URL changes.

It's amusing the first time.  Interesting the second time.
Quite annoying the fifth or sixth time.

What would cause this, so I can prevent it happening, and so that the HPI can
also fix it?

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

On Dec 25, 2007 11:35 PM, Randal L. Schwartz <[hidden email]> wrote:

> Have you seen http://www.swa.hpi.uni-potsdam.de/seaside/tutorial lately?
> Every page link goes through about 8 URL changes.

It is pretty bad, isn't it? I made a program to show what's going on
when I followed a link from that page, and this is what it said, with
apologies for readability:

    Starting with
http://www.hpi.uni-potsdam.de/swa/seaside/tutorial?1&_k=lRXaakpk&_s=ekNqiioEEPonTpbQ
    -------------------------------
    ### 302 Found
      -> server: Apache
      -> location:
http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial?1&_k=lRXaakpk&_s=ekNqiioEEPonTpbQ
    -------------------------------
    ### 302 Found
      -> server: Apache
      -> location:
http://www.swa.hpi.uni-potsdam.de/seaside/tutorial?1&_k=lRXaakpk&_s=ekNqiioEEPonTpbQ
    -------------------------------
    ### 302 Moved Temporarily
      -> server: Comanche/6.2 (unix)
      -> location:
http://www.hpi.uni-potsdam.de/swa/seaside/tutorial?_k=alidjmdR&_s=ekNqiioEEPonTpbQ
    -------------------------------
    ### 302 Found
      -> server: Apache
      -> location:
http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial?_k=alidjmdR&_s=ekNqiioEEPonTpbQ
    -------------------------------
    ### 302 Found
      -> server: Apache
      -> location:
http://www.swa.hpi.uni-potsdam.de/seaside/tutorial?_k=alidjmdR&_s=ekNqiioEEPonTpbQ
    -------------------------------
    ### 200 OK
      -> server: Comanche/6.2 (unix)

It took six requests to retrieve that page. Four of those URLs use the
server name www.hpi.uni-potsdam.de, but two use
www.swa.hpi.uni-potsdam.de. Let's call them Happy and Sappy for short.
Happy is the Apache server; Sappy is Comanche, presumably Seaside.

Sappy served the page that gave the initial link. Happy seemingly
redirects /swa uris to /hirschfeld, but then re-redirects /hirschfeld
ones back to Sappy. Sappy does a redirect of its own (notice that the
_k parameter changes, but the _s session parameter is preserved), but
since it goes back to /swa on Happy, it takes Apache two more tries to
get back to Comanche.

> What would cause this, so I can prevent it happening, and so that the HPI can
> also fix it?

My guess: Somebody tried moving this server to a new hostname, from
Happy to Sappy, but wasn't able to tell Seaside about it. They tried
asking Seaside (or Comanche?) to redirect (??) but that just changed
the _k parameter (and maybe some other internal state?). Then they
discovered that adding a few redirections to the Apache configuration
on Happy got things to work, for a suitably low value of "work", and
that's where things stand today. Conceivably, if it was somebody who
didn't have the Seaside config URL and password, this may have been
the best solution they could manage.

Another piece of the puzzle may be that somebody, possibly the same
person or persons, wanted to make it possible to bookmark the
tutorial's URLs. (The Apache redirects may be an attempt to keep
bookmarked URLs from failing, in fact.) The tutorial in question has a
section on "Static Url" in Chapter 10 that seems partially relevant.

Happy's admin should be able to do in one redirect what the Apache
server is now doing in two, without even breaking old bookmarks. But
the Sappy content, coming presumably from Seaside, is the real
culprit; it seems to be misconfigured such that it thinks it is still
on the /swa path at Happy's hostname. If that alone were fixed, I
think it would take normal clicks down to a single redirection; that
last redirection can either be fixed, justified, or tolerated,
depending upon the phase of the moon, I suppose.

Of course, that's just my guess. I hope that someone else can read
more clearly the story of the evidence, or can confirm that my
interpretation is plausible.

Cheers!

--Tom Phoenix
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

Tom,

Just a hint, you can use curl to trace the redirects in the future,

$ curl -IL
"http://www.hpi.uni-potsdam.de/swa/seaside/tutorial?2&_k=qCjOXJzQ&_s=WPd
jPhAivkXJfbuj"

HTTP/1.1 302 Found
Date: Thu, 27 Dec 2007 19:17:49 GMT
Server: Apache
Location:
http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial?2&_k=qCjOXJzQ&
_s=WPdjPhAivkXJfbuj
Content-Type: text/html; charset=iso-8859-1

HTTP/1.1 302 Found
Date: Thu, 27 Dec 2007 19:17:49 GMT
Server: Apache
Location:
http://www.swa.hpi.uni-potsdam.de/seaside/tutorial?2&_k=qCjOXJzQ&_s=WPdj
PhAivkXJfbuj
Content-Type: text/html; charset=iso-8859-1

HTTP/1.1 302 Moved Temporarily
Date: Thu, 27 Dec 2007 19:12:04 GMT
Server: Comanche/6.2 (unix)
Cache-Control: no-cache
Location:
http://www.hpi.uni-potsdam.de/swa/seaside/tutorial?_k=zBhvczNC&_s=WPdjPh
AivkXJfbuj
Content-type: text/html;charset=utf-8
Via: 1.1 swa.hpi.uni-potsdam.de

HTTP/1.1 302 Found
Date: Thu, 27 Dec 2007 19:17:50 GMT
Server: Apache
Location:
http://www.hpi.uni-potsdam.de/hirschfeld/seaside/tutorial?_k=zBhvczNC&_s
=WPdjPhAivkXJfbuj
Content-Type: text/html; charset=iso-8859-1

HTTP/1.1 302 Found
Date: Thu, 27 Dec 2007 19:17:50 GMT
Server: Apache
Location:
http://www.swa.hpi.uni-potsdam.de/seaside/tutorial?_k=zBhvczNC&_s=WPdjPh
AivkXJfbuj
Content-Type: text/html; charset=iso-8859-1

HTTP/1.1 200 OK
Date: Thu, 27 Dec 2007 19:12:05 GMT
Server: Comanche/6.2 (unix)
Cache-Control: no-cache
Content-type: text/html;charset=utf-8
Via: 1.1 swa.hpi.uni-potsdam.de

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5
http://tinyurl.com/r7uw4

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.
lately? potsdam.de/hirschfeld/seaside/tutorial?1&_k=lRXaakpk&_s=ekNqiioEEPonTpbQ the _______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside