Head, meet wall. Wall, meet head.

[elfs]

RFC 3986:

Note, however, that the "%00" percent-encoding (NUL) may require special handling and should be rejected if the application is not expecting to receive raw data within a component.

Groan. Nothing in the OAUTH spec says that applications may not return '%00' encodes.

I haven't figured out the implications of this yet. I'm using NUL to signal end-of-line within the sort routine. If it's encoded when it goes in (and it has to be, as Apache provides the queryinfo string with a NUL (as opposed to a '%00') to mod_fcgi, mod_webware, and other apache-to-appserver interfaces that way) and it passes through the three-step (decode, analyze, re-encode) without interruption, I'll probably be okay.

If not, crap. I'd hate to have to implement a struct-based, length-stored string handler. Again.

I suspect I'm worrying about nothing at all (well, literally, I am, but that's a different story), and overengineering this thing to handle broken clients (which, if they're borked, probably don't generate valid signatures anyway, right?) with pathological CGI argument encoders.

I hope so. Y'know, this is why we have high-level languages.

Comments

[mouser.livejournal.com]

Gah. If you don't allow it you are virtually guaranteed to break a client here and there, or at least give them "intermittent errors." If you allow it, it could be an attack because those are the sorts of things that lead to an exploit else where.


What are you writing, anyway?


You know - never mind WHAT it is. Do it the way you're supposed to. It may be harder to write, but you'll know that even if something doesn't work CORRECTLY, YOUR part is correct!

[elfs.livejournal.com]

What are you writing, anyway?

An apache authentication module that corresponds to the Open Authentication Spec, Version 0.9(c), I think it is right now.

It has painful little holes like this. I'm trying to hack up a simple little URL normalizer, which would be easy (there are several of them, under several convenient licenses) if it weren't for the fact that, to ensure absolute consistency among URL-based object requests via HTTP, that the argument string (everything from a standing question mark to either the end of the URL or the start of a URI fragment ) has to be sliced by their '&'s, sorted according to their UTF-8 value, then reassembled.

Apparently, some web application server environments get their CGI arguments as hashes, which doesn't preserve their order in the URL, so the OAUTH spec group decided to enforce an order-- an order for which there are no existing C language examples compatible with Apache.

It's a fun little exercise; I haven't written C in ages. But I keep hitting these wedgies in the spec.

[bolindbergh]

1.0 draft 6, apparently.

Including query string parameters even for POST requests? Innteresting....

[elfs.livejournal.com]

Yes. That's a particularly heinous aspect to the specification, because it means that for very large transfers Apache becomes not merely a pipe but a buffer, which it's not meant to be.

I'm tempted to start a campaign to get that removed from the spec on the grounds that it defies everything we know about large file transfers via HTTP; namely, that the server should not have the responsibility for repeatedly seek()ing to the beginning of what came through STDIN until the POST contents are delivered to the final handler.