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

[Tom Phoenix]

On Dec 25, 2007 11:35 PM, Randal L. Schwartz <merlyn at stonehenge.com> 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