Sadly, many Thai web pages are like that. Have a look here and keep a bottle of aspirin handy. This is one of the most popular web portals in Thailand:

Sanook

well, I don't doubt that it's machine-specific, but I think it's machine-specific on the server end, not the client end (i.e., something on the server is identifying different machines correctly but doing something incorrect with that identification). I'm not ASP programmer, but a brief look at the docs tells me that the ASP browser detection system is a bit of a bear to work with. apparently ASP has a whole set of profiles for determining user agents, and an extensible system for creating user-defined rules, all of which is just begging for something screwy to happen.

Microsoft... they refuse to comply with W3 standards that would make browser integration simplistic, and 'compensate' for the problem by creating the world's kludgiest sniffer. yeesh.

As a last resort I fired up XP under Virtual Box and tried Internet Explorer. Same failure. So, I went to the 2privacy.com site to see how the browser is identified:

So, even with the machine identified as an x86, the browser as IE6 and the OS as Windows XP, the server still fails to properly generate the page.

I guess it's time to give up and thank everyone for their help!

Since the problem even occurs in virtual machines, I think it is likely to be something in the networking setup of the afflicted Macs.
You could investigate this by looking at the low level packets being sent (e.g. with "WireShark").

Or just do an "archive & install" (checking the box to preserve users) from the OS X Install CD/DVD to get a fresher start. I say "fresher" rather than "fresh" since that checkbox to preserve users also preserves network settings, so it may preserve whatever (I presume) is causing the problem. In that case, a full "erase & install" might be called for.

except that it happens with my machine, too - do I share a network setup problem with some guy I've never met? I think the archive and install suggestion might be a bit premature...

The sort of problem I'm thinking of is some 3rd-party firewall or other network-related software. It's not that unlikely that you both have the same software installed.
One thing to try might be to do a Safe Boot (holding down the Shift key after the startup chime) and then see if the problem exists.

I tend to agree that it's a networking problem, but I can't imagine what it might be. All the machines are connected to the same router, a LinkSys WRT54G running Tomato version 1.23. All connect via DHCP and all have manually assigned IP addresses. None of the machines have third party firewall software installed and all have the native firewall turned off. The router firewall is on. One, and only one, of the afflicted machines has Little Snitch installed, but it is currently turned off.

The router has QoS enabled, but disabling it didn't help. I tried turning on DMZ for one of the afflicted machines, but that didn't help either.

One of the afflicted machines is a G3 iBook that does nothing but host a web cam. It had a clean install of Tiger (10.4) late last year and the only thing that has been installed on it since then is the web cam software and Apple software updates. In other words, it's about as pure as the driven snow as you can get....

At this point, I'm more interested in actually figuring this out than I am in actually eliminating the problem. It's become an interesting puzzle.

I'll give Wireshark a try. I'm an old retired geezer and no longer the sharpest kid on the block, but at least it will keep me occupied on what looks like a rainy day in the tropics.

It seems that for systems that it doesn't work on, no javascript is being sent at all. This makes me think that it's something to do with the HTTP_ACCEPT headers. See if they're different using this link which should show a little different information about your headers:
http://nerdlabs.org/tools/request_headers.php

If this is right then it is a problem with their ASP code.

Is this what you were after?

The ACCEPT headers look the same to me. Is there something else I should check?

Good News - Bad News
 

The bad news is that the site is no longer working with the PowerBook, where it used to work just fine.

The good news is that I don't have to worry about it anymore. No "good" machine to compare with now.

I wonder if they'd updated the page and you just had one system that was still using a cache. Does anyone still get the reply form?

I just tried to load that page again this morning and get this:

Service Unavailable

and I suspect there's a 'Web Help Wanted' ad circulating around the Thai Craigslist right about now. :rolleyes:

Solution
 

As noted above this web site was down for a while. It's now back up and one addition indicates a probable solution for the trouble I was having. The ThaiJustice web board main page now contains a bright red, scrolling notice that says that the web board policy is that you must have visited the site five days in order to reply to posts and seven days to post a new topic. This notice does not appear on the Thai Justice main page nor on the pages that display individual threads.

This policy is enforced using cookies.

This explains why only one of my machines could "see" the reply form. That's the machine my wife usually uses. And, she uses whatever account happens to be logged in at the time. That's why I could see the reply form on that machine from my account, but not on any other machine.

The crazy thing is that although they use the cookies to decide whether or not to display the reply form, they continue to display an anchor link to the reply form [<a href="#wwbaaddfm">คลิกที่นี่</a>] at the bottom of the page even when the reply form is not there.

Unfortunately this does not explain how acme.mail.order was able to download the page source, including the reply form, using curl.