API and other raw pages may be accessed only from main entry point

(In reply to comment #1)

API and other raw pages may be accessed only from main entry point

That doesn't mean we can't do an HTTP 302 to it, does it? (Please correct me if I'm wrong, which would mean IE is even more brain-damaged than I give it credit for. CCing to Brion to check.)

Anyway, added [[Special:API]] in r30537, which just HTTP redirects to api.php. Stuff like [[Special:API/action=query&list=allpages&aplimit=5]] also works.

Ya, redirect was one of my thoughts.

Though, actually the reason why I suggested the / separation, is because of the differences in short and long urls.

With that setup, this would work:
/wiki/Special:API/action=query&list=allpages&aplimit=5
As it would redirect to something like:
/api.php?action=query&list=allpages&aplimit=5

However, long urls offer up:
/index.php?title=Special:Api/action=query&list=allpages&aplimit=5
Which will actually redirect to:
/api.php?action=query
Because the & is considered part of the actual query. It's also not possible to externally detect things like that, because it's possible that someone may be using path to query rewrites which do have the & issue, but no ? exists in the url.

That's why I suggested the / separated format where all the /'s would be replaced with &'s and put into the query. Because it works universally no matter what the setup.

(In reply to comment #3)

Ya, redirect was one of my thoughts.

Though, actually the reason why I suggested the / separation, is because of the
differences in short and long urls.

With that setup, this would work:
/wiki/Special:API/action=query&list=allpages&aplimit=5
As it would redirect to something like:
/api.php?action=query&list=allpages&aplimit=5

However, long urls offer up:
/index.php?title=Special:Api/action=query&list=allpages&aplimit=5
Which will actually redirect to:
/api.php?action=query
Because the & is considered part of the actual query. It's also not possible to
externally detect things like that, because it's possible that someone may be
using path to query rewrites which do have the & issue, but no ? exists in the
url.

That's why I suggested the / separated format where all the /'s would be
replaced with &'s and put into the query. Because it works universally no
matter what the setup.

Slashes are also bad, because pagenames can contain slashes. Then again, they can also contain ampersands. It should be noted that ampersands did work when urlencoded.

Anyway, that's all moot now, because Brion reverted my commit. The path to api.php can be gotten quite easily through other means (like grabbing the wgScriptPath variable through JavaScript and appending /api.php).