Geoffrey Swift's βlog

It's been a while since the last rant, here are a few serious concerns for web developers to consider!

Resending POST data

The "back" button is very useful feature to have in web browsers. Unfortunately you can be prevented from going back to a page that is generated in response to filling in a form.

When you try to do this, the browser explains that the page can't be displayed without resubmitting the form data. This is since there are special rules which generally prevent an HTTP POST response from being cached.

So you can either resubmit the form, but you might not get the same results the next time around. There is no option of just seeing the original version of the page. The browser could ask you whether you wanted to see the old version, and could perhaps warn you that showing you the old version would be in defiance of web standards. This has to be an improvement over what is essentially a flat refusal to behave intuitively.

Web programmers can work around this problem, by making a web server respond to a web browser's posted form data appropriately. The solution is to instruct the web browser to be redirected to another web page, which can retrieved conventionally. This page you're redirected to appears in the browser's history instead, so your back button can work as normal.

For further technical details, I recommend reading the HTTP RFCs and the Wikipedia article on the "Post Redirect Get" pattern.

Click to close window

Many web pages, particularly those in popup windows have a hypertext link entitled "Click to close window". I feel this is redundant, since web browsers windows can be closed like any other. Given that web browsers open new "windows" as tabs, the wording itself isn't quite right either.

The only case for having such a link is for popup windows created in such a way to specifically hide the standard close window option. Even so this appears to be a case of trying invent a rounder wheel.

Print friendly version

When viewing websites like Google maps, it can be useful to make a hardcopy so you can review the information later. Unfortunately what you see on screen doesn't necessarily work so well on paper. This is what prompts web developers to create a "printer friendly" version.

While this seems like a great idea, I feel this is really just a sorry excuse that they couldn't figure out how to make a web page that appears correctly both on screen and on paper.

There exists a useful feature in CSS2, which lets you define formatting based on the "media" being used. You can use this to make your web page to look totally different when printed.

For an example of this in action, try using the "print preview" option in your browser when looking at my website. You should see immediately that the navigation menu disappears and background colours are turned off.

A useful article on this can be found on about.com

The strace utility is well recommended for investigating all manner of Linux problems. But while using strace to debug a crash in the Linux version of my Talker application, I came across something which proved to be a red herring. It appeared that select() was failing and setting errno to ERESTARTNOHAND.

Without being side tracked by what that would have meant, the actual problem itself was actually a segmentation fault had happened in another thread. select() was actually setting errno = EINTR, due to the corresponding SIGSEGV signal.

The error outside of the main thread was only apparent when using strace -f. The "follow forks" option is necessary, since pthreads works by forking off new Light Weight Processes (LWPs).

I found plenty of posts on the web detailing similar issues, although no solutions offered. Hopefully this information will be helpful to someone else.

Implementing my radio player took more experimentation and research than actual coding. As with most software, things turn out more complicated than first anticipated!

To tune in into an Internet radio station, normally you would click on a link on the station's website. From this link your browser will download a play list file, which in turn contains the URL that your favourite media player can use to access the station's live stream. My goal was to make this accessible in a more convenient manner, by allowing access to several radio stations in one place.

So I decided to create my own play list file that contained all the relevant URLs for my favourite stations. I wrote a PHP script that would generate this this play list by downloading each station's play list and extracting the relevant stream URL.

Play list file formats

There are three main formats used for these play list files, which are ASX (Windows Media Player), M3U and PLS (WinAmp).

Easiest to parse was M3U, this is just an ordinary text file that has the URL as a line of text. As PLS is an INI file, this seemed easy using PHP's built in functions to parse INI files. I quickly found that the PHP functions were unreliable so I wrote a kludge to get the URL myself, using a simple regular expression.

In a previous article I discussed problems with ASX files not being XML, so I avoided using this format unless the station did not also offer M3U or PLS. By sheer luck the few stations I am accessing via ASX are well formed XML. Unfortunately the structure of these ASX files vary, so it took a few iterations of the XSLT code to extract the stream URL realiably.

The file format I ultimately create my play list is is XSPF, as this is a well defined format based upon XML. From the master XSPF play list, I can readily generate ASX, M3U and PLS by using XSLT. Having the playlists available for means good support for tuning in with various different media players. I would personally recommend using the XSPF play list in VLC Media Player.

Streaming from a web page

I felt the stations should ideally be available directly a browser, without requiring an external application to be installed. After trying a few different options I opted to use the "XSPF Web Music Player" written in Flash. Getting Flash working is an exercise in itself made easy using the UFO JavaScript library. This setup offers good compatibility with typical browser setups.

Fixing the stream URL

The biggest problem with this was presented by a strange behaviour of Shoutcast servers. When you access the stream URL for a Shoutcast server using a web browser, you are served up a web page about the stream. This HTML content is provided instead of the MP3 stream, on the basis of the User-Agent header of the HTTP request.

Generally browser plugins have their HTTP requests made for them by the browser, so HTML content is delivered to a Flash movie or a Quicktime regardless. The exception to this is the Windows Media Player plugin, which bypasses the browser completely; disregarding proxy settings etc.

Shoutcast servers do provide a special URL that allows you to ensure the MP3 stream is returned regardless of the User-Agent. You just append ;stream.nsv for example http://example.com:1234/ becomes http://example.com:1234/;stream.nsv.

Appending this string confuses any servers that aren't using Shoutcast though. So it became necessary to probe each server, to adjust the URL where required. This works by impersonating Firefox and when HTML comes back, that's Shoutcast.

Memory usage

One significant problem appears to be that of memory consumption while listening to a stream. If you're listening for a few hours or so, expect your memory usage to be in the 100s of megabytes. This is enough to cause problems in a typical PC setup. A workaround for this is to stop and restart the stream occasionally.

The reason behind this is that the MP3 stream is treated as if a very long MP3 file is being downloaded. What you've heard so far remains in memory even though, with the exception of Real Player, you can't seek backwards. This is a well known problem that affects nearly all media players and browser/plugin combinations except VLC Media Player.

Recommended use

If you use the M3U or PLS play lists, you may well just see IP addresses and port numbers rather than meaningful station names. This is a limitation of the file formats used, and isn't fixable. Using the XSPF play list is recommended as it has the station name and website link. Also you can use the XSPF play list in VLC Media Player, without having to worry about your memory usage.

I have been working with various playlist file formats as part of my internet radio project. This has involved creating XSPF playlists from XML sources and using XSLT to convert from XSPF to the alternative PLS and M3U formats.

According to the Simple ASX article on MSDN: an ASX file is an eXtensible Markup Language (XML)-based text file which references a Uniform Resource Locator (URL) for a piece of media content. Having read this I felt that ASX files ought fit neatly into my XML and XSLT based architecture. Only when implementing this, did I discover that ASX actually has quite limited compatibility with XML.

The XML validation tool xmllint rejected a couple of ASX files, since they included the copyright symbol © encoded using ISO-8859-1. It seemed easy to solved this problem, by explicitly specifying the encoding in the XML declaration e.g. <?xml version="1.0" encoding="iso-8859-1"?>. Although the file could then be validated as XML using xmllint, Windows Media Player would simply not load this modified ASX file. It was then apparent that ASX is not compatible with XML.

Some URLs referenced in ASX files may well have query strings, which are of course delimited with ampersands. After seeing a few of these I noticed that none of the ampersand characters were escaped as they should be in XML. For a well formed XML document, a literal ampersand charater should be represented using an escape sequence, e.g. &.

I edit an ASX file to make it valid XML, by ensuring the appropriate escape sequences were used. The play list came up in Windows Media Player, but it did not play as expected. When looking at the properties of the relevant track in Windows Media Player, the text & could be clearly seen as part of the URL. Although I had made an ASX file into a valid XML document, once again this was futile since the ASX file was not interpreted as intended.

To summarise here are some quirks of ASX files that make it incompatible with XML:

• The default encoding for ASX appears to be ISO-8859-1.
• An XML declaration cannot be included in an ASX file.
• Ampersand characters in ASX files are parsed as literal text and should not be escaped as &.

To work around these problems, I wrote a PHP script that downloads an ASX file and converts it in an XML format. To achieve this it simply escapes all the ampersands, and serves this modified content with an appropriate HTTP header for ISO-8859-1 encoding: Content-Type: text/xml; charset=iso-8859-1. Aside from XML incompatibilities many ASX files are tag soup. My PHP script therefore includes kludges to address problems specific to the ASX files I'm working with.

This wasn't quite the clean solution I originally had in mind, but I am now able to import from multiple ASX files across the web. It was less trouble working around PHP's woeful ini file parsing routines to get the PLS file format supported, but that's another story!

Text size changing underneath mouse pointer

It might seem like a nice idea to have text become bold, or even larger when you position the mouse over it. But this can cause problems when the layout of the page is affected.

Suppose I position my mouse over such text, and it gets bigger. This can cause the text to be moved away from the mouse pointer, which means that the text reverts to its original size. Once the text has shrunk back to its original location under the mouse, it then grows and the cycle repeats until the mouse is repositioned.

My suggestion is to only do this if you can be sure you will not be affecting the layout of the web page. For example make sure the text is bounded within a box that is large enough for the text, regardless of whether it is enlarged by the position of the mouse.

Redirecting to an error page

Occasionally websites have problems, and so it is appropriate to display an error to the user. Rather than having the desired web page display an error, some websites redirect to a dedicated web page that explains an error has occurred.

Errors quite typically are due to a temporary glitch, and so you might expect to be able to use the refresh button in your browser to reload the web page. If you've been redirected to a separate page this isn't possible, even clicking back will redirect you to the error page again.

Instead it seems necessary to click back in rapid succession, before the redirection kicks in. That way you can once again attempt to repeat the steps required to load up the problematic page. This may involve filling in a form once again, but either way this is not user friendly! It would be preferable to display error messages on the web page the error occurred, so that it's possible to simply click refresh.

What country am I in today?

Lots of websites have forms that let select your country. Unfortunately these websites generally have a large number of different countries to choose from. I find this means a regular chore of guessing which country to look for, the right one could be any of the following: Britain, England, Great Britain, United Kingdom or UK. The only option I haven't come across is the actual name of the country where I reside, the United Kingdom of Great Britain and Northern Ireland.

So to anyone writing a web pages with forms allowing a choice of countries. It would be nice to see a default country value determined using a country IP database. That would make things a bit easier.

"Back to" … the future

A lot of sites have links with text such as "Back to homepage", or "Return to to search results". But you may have accessed the page via a link on an external site or even a bookmark. So the wording of such links presumes that a visitor to the site came via the web page that's linked "back" to. My suggestion is to leave out the word "back", as it is fairly redundant and potentially inappropriate.

There are lots of interesting tips and ideas relating to programming techniques and related principals bandied about. The people who advocate them have all sorts of different backgrounds, and undeniably it can be very useful to draw on the experience of others.

Some techniques are devised to solve problems that are common to all programmers alike, but the significance of an underlying problem addressed will vary for each project. While something may be critically important for you, it could well be of insignificant concern to somebody working on a different project.

Each programmer faces difference challenges, and has difference experience - so the solutions they come up with are quite personal to the individual. For example a programmer may advocate a technique that merely addresses a problem specific to certain programming languages, or is specific to the size/complexity of their application or even their development team.

Techniques in computer programming have evolved significantly over time, and opinions are constantly changing. This is no surprise, considering the rapid pace of change in what software is used for and how it is used.

Because of this, I feel it is important to have an awareness of various different techniques. In each new scenario it's then possible to decide what is the most appropriate technique, treating each case on its merits.

Programming is a complex task and difficult to make generalisations about. There are many tips floating around that contradict one another, and have no explanation of what the basis for them is. It is more difficult to evaluate a technique, without some explanation of what its purpose is.

From my referer logs I've noticed people looking up problems with XHTML, JavaScript and CSS. Hopefully some web designer will read my pet peeves below, and mend their ways!

Bad support for font resizing

I use a relatively high resolution 1600*1200, and so most websites look small to me. When I increase the font size in my browser (Firefox) to compensate, the layout of most sites become a complete mess. Typically words are crammed into columns that just look too narrow, or text becomes illegible because it no longer fits inside its containing box. This problem typically occurs because dimensions have been stipulated using pixels in the CSS code, but this will go wrong for other fixed unit of measurement. So when you're coding up your layout using the "box model", try using only em, ex or percentages instead of pixels and the layout should resize in proportion with the text.

Login forms setting focus away from password

Many websites have login pages, which set the focus to the user name field when the page finishes loading. This might sound like a great idea, but not while I'm in the middle of typing in my password! I don't really want half my password in the password box, and the other half plainly visible in the user name field. This is another quite common problem. A simple fix might be to only set focus on the user name field, when it is empty.

Click to enter site

There still seems to be no shortage of sites, with a main page that just says "click to enter site." The fact that such a page actually is the website, seems to be lost on the web designer. Unless there's a good reason for having such an entrance page (like a disclaimer) just let people surf straight in to meaningful content without any such inconvenience.