Warmup #1
250 Word challenge:
Walk a person across a room.
250 Word challenge:
Walk a person across a room.
There’s likely going to be a bit of random noise this year on my blog with regards to National Novel Writing Month. In previous years, I’ve had a plugin setup in advance to filter NANO-related posts from my standard RSS feed. This year, well, I haven’t had enough time to set one up, but the forums are so lagged I’m about to start posting here in lieu of waiting for the Nano forums to start working. Apparently, they didn’t anticipate quite the amount of usage the servers receive at this time of year… just like they didn’t last year.
“To help struggling homeowners, the plan requires the government to try renegotiating the bad mortgages it acquires with the aim of lowering borrowers’ monthly payments so they can keep their homes.”
Deal reached on financial markets bailout
Obviously, I should have gotten a highly suspect mortgage two years ago, rather than actually reading the fine print and deciding NOT to gamble with my financial future. Had I done that, Super Government would save me, too!
EDIT: Proposed legislation. Reading it now.
What a surprise! Except, not.
You are a Social Liberal (60% permissive) and an… Economic Conservative (61% permissive) You are best described as a: Link: The Politics Test on Ok Cupid |
That’ll be all, ye scurvy scoundrel!
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.
I’ve recently (finally) burned the majority of my pictures to backup DVDs. I kept the ones that were halfway decent or better, but I have some that are utterly unnecessary to keep.
Unfortunately, that meant I needed someplace to put twenty archive DVDs. I don’t have cases handy (working on it, believe me), but in the meantime, I have a half-dozen CD binders from my college years that I figured I could misappropriate. So I tracked down a couple of them (a guy couple — three (I had this argument with a female friend in college; I asserted that “couple” meant “2 or 3”, she took the monogamous definition. Oxford English Dictionary agreed with me… just sayin’)), and began consolidating. WOW I have random stuff kept.
Read more
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?