no_server_init side effects

[Trott]

The no_server_init stuff has some bad potential side effects that are coming out of testing.

The first time you go to a site, you get a ?no_server_init tacked on to the end of your URL.

If you cut and paste that URL to send to someone else, saying "Hey, check out this awesome site!", and they put it in their browser, they end up with the basic site rather than the full site.

[ebollens]

I agree that this is a possibly challenging side-effect, but I don't think we can have our cake and eat it too.

• If we want to prevent the redirect loop without cookies, we have to pass a URL parameter.
• If we pass a URL parameter, then we have to trust it.
• If we trust the URL parameter, then when it is there, we can't refresh the page.

I'm going to go ahead and tag v1.3.00, but I'll leave this issue open for the time being. Let's discuss during the next core developer meeting.

[Trott]

One possible ambitious solution is to eliminate the cookies altogether. Much (all?) of the cookie content is actually unneeded. If nothing else, we should at least get rid of the unnecessary stuff to keep the payload small. Here's how I see it:

• Screen cookie: Probably not needed. Most of what it's good for might be better handled with responsive design/progressive enhancement/media queries. There are pitfalls there too, but they're pretty well documented. (For example, you want to avoid media queries that are formulated such that images are downloaded by the client but never used.) The pitfalls we have with the redirect stuff, on the other hand, are uncharted waters. The only use case for the screen cookie that I can think of that may be somewhat compelling is for passing parameters to the image minifier. But even that doesn't seem terribly compelling, and can probably be handled adequately with responsive design and/or JS DOM writes. Using the screen cookie contents with the image minifier also has pitfalls, like having markup for a large screen cached by a proxy that then serves it to a smaller screen. Progressive enhancement/responsive design avoids that issue.
• User Agent cookie: If nothing else, this cookie's size can be way reduced. There isn't any need (that I know of, anyway) to pass the long, gangly user agent string inside the cookie. The server side already has access to the user agent string. The rest of the info (e.g., OS) may be useful, although it would be interesting to see just how much use it gets in real-world installations and whether its really more useful than other things people might be doing.
• Classification cookie: This is the hardest nut to crack, perhaps. Even thinking about getting rid of this means a total reworking of the default style sheets using progressive enhancement. Well, either that or relying on JS to load the standard and full style sheets, which probably will reduce the efficiency. The progressive enhancement redesign is something we should be exploring anyway.

Even if we fail in this attempt to deal with this minor issue (and any other issues, major or minor) caused by the cookie/redirect stuff, pretty much all the things we'd be doing are things we ought to be looking at anyway.

[ebollens]

This makes sense to consider for 2.0 - we can think about a strategy that gets rid of these completely.

However, as we at least have MWF 1.4 still coming down the current vein, they need to stay for the time.

The suggestion Ed and I put together and approved by Core Dev meeting today is to add a timestamp to no_server_init parameter.

[Trott]

If we go the timestamp route, it is probably worth mentioning in documentation that all servers should be sync'ed to an NTPD server or something similar since a timestamp that is off by a few minutes could result in endless redirect looping....

[ebollens]

For passthru.php, the timestemp would be both set and ready by the MWF server, so it wouldn't need to be synced unless some institution were running multiple MWF servers and load balancing on a request-by-request basis.

However, there is indeed a clock skew issue for the local refresh case. If I reload via Javascript, then the GET parameter is defined by logic on my computer, not on the framework server. This makes the logic dependent on a sync between my machine and the framework server. One alternate approach would be to actually pass a timestamp into the Javascript as a hardcoded variable - but I need to think over the caching case here a bit more first.

[ebollens]

I'm going to close this without rolling out the timestamp fix. It makes it possible to end up in an infinite loop in theory, whereas the counterpoint is simply one screen displayed as basic rather than full - the latter is definitely less invasive.