One of my clients has a site that downloads a series of results as a CSV file, which they open in Excel. Unfortunately, Internet Explorer was refusing to download the file, and was presenting an error message reading “Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found.”

To add to my confusion, this was happening on the live server (PHP4), but not on my dev server (PHP5) which both use the same code.

In the end, I happened upon a Microsoft Knowledge Base article that explained the problem. Basically, IE obeys any “no-cache” headers you send to the browser. Without caching the file, Office applications cannot open the file when served over HTTPS.

How to solve the issue? Remove the cache header(s) - but how?

The PHP manual doesn’t make it entirely clear, and I found the solution by accident. To remove a header, use the same syntax as for setting a header, but only include a space after the colon.

For example, for the “Pragma” header:

header('pragma: ');

Note: You must include the space after the “:” or the header will not be unset.

In 99% of cases, all our sites look the same in Firefox 3, apart from one notable exception. In this one case, there is a 1px gap between the left-hand margin (which is centred using “margin-left: auto”) and the header image. Being the perfectionists we are, we don’t want a 1px white gap in our nice header.

Oddly, this 1px gap would come and go as the browser window is horizontally resized. This behaviour set alarm bells ringing that it’s some kind of rounding error in the “auto” positioning vs the exact pixel dimensions of our centred container.

After a bit of searching, we found an entry in John Resig’s blog (of JQuery fame), where he has stumbled upon the issue and developed a test case for the main browsers. Turns out that fixing it is a challenge, as all the browsers round the numbers differently. Problem is, there’s no standard for how the browsers should round the pixels, so fixing it in one browser will almost certainly break it in another.

Ho hum, here’s hoping for a future standard.

In this three-part article, I give a brief introduction to file and directory permissions, as well as some of the common gotchas. This part shows you how to interpret permissions on the command line and explains what they mean.

One of the best ways to get a feel for the permissions, is using the shell. So, if you launch a shell session and type the following: (the “-l” means the long-listing format)

ls -l

You’ll see a listing of all the files in your home folder, something like this:

drwxr-xr-x  2 dan users    4096 2007-12-13 15:34 bin
drwx------  5 dan users    4096 2008-07-25 15:30 Desktop
drwx------ 15 dan users    4096 2008-07-18 10:49 Documents
drwxr-xr-x  2 dan users    4096 2007-12-13 11:08 public_html
-rw-r--r--  1 dan users   12094 2008-03-10 15:22 readme.txt

Of particular interest to us, is the first set of characters which represent the permissions: (numbered below, for reference)

drwxr-xr-x
12345678910

From left to right, the permissions are grouped into four parts:

• Character 1: Indicates a directory (d), link (l) or normal file (-)
• Characters 2-4: The read (r), write (w) and execute (x) permissions for the file owner (”dan” in the example above)
• Characters 5-7: The read (r), write (w) and execute (x) permissions for the file group (”users” in the example above)
• Characters 8-10: The read (r), write (w) and execute (x) permissions for everyone else aka others

What these permissions mean, depends on what kind of file it is.
For directories:

• Read (r): Users can view a listing of the directory contents (i.e. read its contents)
• Write (w): Users can create / delete files in this directory (i.e. write to the directory’s contents).
• Execute (x): Users can enter this directory using a “cd” command

Note: If users have write access to a directory - they can delete its files even if they are not the owner and/or do not have write permission to the individual file. Watch out for this one, it has caught us out in the past!

For files:

• Read (r): Users can view the files’ contents
• Write (w): Users can modify the files’ contents
• Execute (x): Allows execution of the file as a program

You should also be aware that Linux only checks the most appropriate permissions when deciding whether to grant access. For example, if you are the file owner, only the owner permission is checked (not the “group”, or “other” permissions). This means, if the permissions are “—-r–r–”, you won’t be able to read the file if you are the owner - whereas members of the file group and “others” will be able to read it.

That’s it for now! In the upcoming part two, I will detail how to set permissions, using the Linux command line. Part three will show you some of the more advanced permissions. Watch this space!

At work, we were using some software which, somewhat curiously, seemed to automatically log users in without them supplying the correct credentials. After much digging, inserting debug messages and experimentation, I found that PHP had the authentication values in the superglobal $_REQUEST array. The values you can use are as follows:

1
2
3
4
5
6
7
8

// Superglobal showing the username supplied
print $_SERVER['PHP_AUTH_USER'];
 
// Superglobal showing the password
print $_SERVER['PHP_AUTH_PW'];
 
// Authentication type (Basic or digest in PHP5)
print $_SERVER['AUTH_TYPE'];

This is immensely useful for me, because it opens all sorts of possibilities for single sign-on style systems. It also means I can work with non PHP files, without having to authenticate twice or rely on PHP sessions alone.

Of course, perhaps I should have looked at the PHP manual on HTTP authentication first!

Last year, during @media 2006, I was introduced to the concept for the first time. In its simplest form, it’s a way of wrapping web content within a set of standardised class names. The idea being that if everyone uses these class names, it makes it very simple for other systems to parse and pluck out the data. The example given was marking up personal details as an hCard which could then be linked to the Technorati contact generator. The generator will parse the page and offer you a vCard file for download, which you can then import into Outlook or some other address book software.

For example, I may have some contact detail about myself:

Name: Dan Forys , website: http://www.danforys.com

To “microformat” it, I could do this:

<div class="vcard">
Name: <div class="fn">Dan Forys</div>,
website: <a href="http://www.danforys.com/" class="url">http://www.danforys.com/</a>;
</div>

Simply by applying the classes “vcard”, “fn” and “url”, I have specified that the information contained within is in the “hCard” format. Now, the browser, another website, or some other software could read this page and fetch that information - perhaps offering to put it in the user’s address book. Simple!

At the time, I was somewhat skeptical - since it seemed very much a developer-centric technology. Unless the site developer had the foresight to embed something in the page (like a link to the Technorati generator), the user would not be able to do anything with the data. Basically, microformats depend 100% on the site developers marking up their code appropriately.

Fast forward to 2007, and I’d more-or-less forgotten about microformats until the @media talk by the massively intelligent Tantek Çelik. This time, I’m much more enthusiastic about the whole idea, this is why:

• Firefox 3 will have support for microformats built-in
• (and this is mainly what’s converted me to the idea…) The Operator extension for Firefox automatically highlights microformatted information and offers you ways of working with it (download a vCard for example) - No linking necessary!
• There’s a set of open-source tools that can be used to interpret microformats that can be installed on your own site - or you can link to externally hosted ones like at Technorati
• There are tools allowing you to perform SQL-like queries on microformatted pages (I guess through XSLT or just parsing the pages…). Although rather complex, it lets developer do wonderful queries on pages to extract exactly the data they require. Effectively, it lets developers mash-up microformatted websites.
• By using (X)HTML class names, there is no need to change the meaning (semantics) of the markup used - it also lends itself very well to applying CSS to the information (of course, CSS has its own class selectors for you to use…)

I firmly believe that once the browser support is there, this is an excellent way of doing things. I wonder if Microsoft will follow Firefox’s lead with this?

Working in an academic institution, microformats are a great tool for us - we have hundreds of personal profile pages for the staff here. It would be great if they could be marked up to let visitors easily add the information into their address book. It just so happens that we’re needing to rewrite the profile pages anyway to better organise them. Also, we have an events system that would lend itself very well to the hCalendar implementation - which we are also looking at rewriting.

In our case, there’s a couple of teeny barriers to implementation that need some thought though:

• Staff are (understandably) twitchy about publishing their personal information on the web and microformats make it much easier to harvest that information. In reality though, their information is already on the web - but the perceived problem is that they might get pestered more from the outside world (eek!)
• Calendar events are not implemented consistently across the major players (MS Outlook, Google calendar etc.). After some initial experimentation, my line manager found that a different event download needs to be offered for each calendar application. Of course, this is certainly not the fault of the microformats spec. Can we have a consistent and quirk-free calendar file format please?

Still, these are relatively minor issues and microformats have been developed to encompass a lot of useful data types (events, contacts, resumes, reviews to name a few). So I think this is something we’ll be incorporating here as much as we can.