Consistency is key

On top of the aforementioned SERVER ERROR 500 issue occuring because I didn’t specify a USER_AGENT that matched the white list, I’ve been spending the last week trying to track down exactly why I couldn’t upload a file. I used the stock GalleryRemote program (isn’t sufficient for automation purposes) to test my server, and it all worked fine.

Well, after over a week (admittedly, I’m only poking it on the bus every few days, and only while driving into work), I managed to puzzle out enough from the source code of the Gallery Remote to figure out why my code wasn’t working.

If you’re executing a command, your message must be:
application/x-www-form-urlencoded

However, if you’re trying to upload data, your form must be:
multipart/form-data

Apparently, the system DIES if you try to consistently use one or the other. The former is simpler; the latter provides better performance for binary uploads. Mind you, this isn’t commented ANYWHERE.

I can understand the usage of the former when possible, and the latter when necessary. I can almost understand why no one bothered to mention it (After all, the W3 recommendation for form submission clearly indicates to use both as necessary). However, what I can’t understand is WHY my usage of the latter in all cases isn’t mapped the same way within PHP.

I mean, come on! Regardless of the way the data is submitted, the application platform should, for purposes of the dictionary-based lookup that PHP provides via the $form variable (I think that’s right, I don’t speak PHP), shouldn’t both submission mechanisms be abstracted away unless you want the added complexity?

I’m tired and have a cold, otherwise I would extend this rant into the direction of work. However, you may all count yourselves lucky. For I am going to sacrifice a kitten to my desire to snuggle something cuddly when I don’t feel well, and then I am going to bed. Nice deal, eh?

EDIT (16 Sept 08): Err. Maybe my bad. Turns out that while, by convention, a multipart/form boundary is specified as “———-” + RandomData, the actual usage as a boundary requires it to be prefixed with an additional two dashes. In other words, the actual, in use, boundary should be “————” + RandomData. Which, if you try to just look by eye, is far from visible. Unfortunately, if I had paid more attention to the documentation, the example they give isn’t prefixed by a series of dashes, and it’s far, far clearer. Still could have been explicitly documented (ABNF, anyone?). However, I’m not going to lambast the PHP team; they could have been working just fine all along.

Gallery Remote 500 Error? Read the code.

I’ve been following the dreadfully incomplete and near-incomprehensible documentation on how to access Gallery2 remotely. It’s not SOAP, it’s not REST. It’s custom formatted form submission.

And everything seemed to be working. So I kept going through the checklist of available commands, and then it stopped.

500 server error. No actual diagnosable response.

I’ve updated my Gallery2 install to the current release candidate. I’ve custom built ImageMagick locally. Nothing worked.

Then I came across a small, barely commented bit in gallery2/modules/remote/GalleryRemote.inc — “harmless” get-type operations are permitted. However, anything that attempts to make changes is verified — against a white-list of USERAGENT strings.

I have no idea who considered THAT a security feature, but adding a new USERAGENT to match my C# library’s USERAGENT, and everything suddenly works.

“Open” Source, huh?