non-unique percent-encodings make static responders hard to build

[iay]

The spec as currently drafted relies on STD66's notion of percent-encoding IDs. That encoding scheme has some deliberate ambiguity in terms of what specific string should result from encoding.

For example, although some characters (e.g. \) MUST be percent-encoded, any character MAY be percent-encoded. This means that an MDQ responder MUST regard the following as equivalent:

foo:bar
foo%3Abar

The A to F characters in the encoding MAY also appear as a to f without changing the semantics. STD66 says that encoders "should" (note, not even SHOULD) use upper case, but the result is that an MDQ responder MUST regard the following as equivalent:

foo%2fbar
foo%2Fbar

This is easy for an "active" MDQ responder implementation to deal with. It's harder for people who are trying to implement MDQ by just putting a set of carefully named files behind a standard web server.

In practice, most encoders appear to use upper case. It's not guaranteed, though, and this may cause compatibility issues. It's probably worth at least highlighting this behaviour in the MDQ base spec. I don't think it's worth profiling STD66 within MDQ such that upper case is required (and over-encoding is forbidden) but that might be a discussion to have.

[rhyssmith]

Apache HTTPD seems to generally deal with this quite well. It will generally serve content when the request is either literal or percent encoded, and if percent encoded, whether it's upper or lower case.

• So e.g. if the backing file is foo:bar then requests for foo:bar, foo%3Abar, and foo%3abar are all served correctly.

One wrinkle is that for requests with / in, to get Apache to deal with that properly one must use the AllowEncodedSlashes NoDecode directive, meaning that %2F should make its way through apache literally without decoding. This means that %2F and %2f come through as-is, and thus requests with a lower/upper case encoding that don't match the backing file will fail.

• So e.g. if the backing file is foo%2Fbar, then requests for foo%2Fbar is served successfully, while foo%2fbar is not. (Note that a request for foo/bar is invalid since / is one of the characters from the reserved set that MUST be percent encoded).

This wrinkle can be sorted in Apache however with a mod_rewrite rule that simply upper-cases any lower case %2f: RewriteRule "^(.+)\%2f(.*)$" "$1\%2F$2" [L].

So, with a few configuration options and rewrite rules in place, this doesn't seem to be too big an issue for a "passive" MDQ responder where the responder is something capable like Apache HTTPD. Obviously if one tries to do this with IIS, YMMV (by a large amount!)