PHP disabling a Semantic Web Enabler?
| By hannes @ 20:52 | [ PHP Hypertext Preprocessor ] |
Looks like a reasonable (although disputable) solution to the problem, there are advantages over special HTTP headers, URI suffixes and other approaches which are explained on the URIQA website. Special headers could just be ignored by a server, and usually they are. But if you introduce new HTTP verbs, servers will not know them and should return an error. Apache does, so all seems ok.
Enters PHP. As people wanted to use PHP to, for example, implement WebDAV, they patched their SAPI and pass all HTTP methods to the script requested.
Means you don't have to apply funny workarounds any more, but also means that agents/clients can not rely on the result of queries with those new methods: PHP scripts will return their usual output, not caring about whether you GET, MGET or SHOWMETHATSHIT them:
hg@hg2:~$ telnet gassert.ch 80
Trying 213.3.6.224...
Connected to 224.6.3.213.fix.bluewin.ch.
Escape character is '^]'.
MGET /showmethod.php HTTP/1.1
Host: gassert.ch
HTTP/1.1 200 OK
Date: Wed, 12 Jan 2005 20:05:44 GMT
Server: Apache/1.3.31 (Unix) PHP/5.0.3RC2-dev mod_gzip/1.3.26.1a
X-Powered-By: PHP/5.0.3RC2-dev
Transfer-Encoding: chunked
Content-Type: text/html
It's Wednesday 12th of January 2005 09:05:50 PM
Your request method was MGET
As you can't tell if your request is handled by a PHP script (mod_rewrite et cetera), this does look like a bit of a problem for URIQA, because PHP (+ Apache 1.3.x) is all over the place indeed. Doesn't it? Does PHP kill this nice idea of this Semantic Web Enabler?
It's just my second day here at the Semantic Web Cluster, so I might very well just misunderstand the concept and there's no problem at all for anybody?




