This approach has one large pitfall, which you are only guaranteed to sidestep if you control the web server. I mention it here as a caveat to whoever might pick up your code and then wonder why it fails at inopportune times.

The set of fields in an IIS logfile is adjustable via the IIS control panel. When IIS starts a new logfile, it prints the names of the fields that it will log in a #Fields: comment. IIS lets you change this set of fields in mid-log, and then emits a new #Fields: comment into the log in mid-stream. Boom. There goes your script.

Does this ever happen in practice? It has to me. I've seen our network or support folks change the set of fields logged while they're diagnosing connectivity problems. Even if they're aware that it's going to cause analysis problems, that's easy to overlook in the heat of battle, or write off as SOP (Someone Else's Problem).

The code snippet that demonstrates how to cope with this is here, posted by your truly as an early contribution before I registered at the Monastery. In brief, it introduces an level of indirection by way of a hash. It'll probably introduce a small-but-measurable performance hit, which you'll need to weigh against the risk of your script failing at the worst possible moment.