|
|
@ -27,7 +27,7 @@ of reasons:
|
|
|
|
* Even if client implementations do remember to URL-encode their parameters,
|
|
|
|
* Even if client implementations do remember to URL-encode their parameters,
|
|
|
|
they may not do it correctly: many URL-encoding implementations may be
|
|
|
|
they may not do it correctly: many URL-encoding implementations may be
|
|
|
|
intended to encode parameters in the query-string (which can of course
|
|
|
|
intended to encode parameters in the query-string (which can of course
|
|
|
|
contain literal slashes) rather tha the path component.
|
|
|
|
contain literal slashes) rather than the path component.
|
|
|
|
|
|
|
|
|
|
|
|
* Some proxy software may treat `%2F` specially: for instance, Apache, when
|
|
|
|
* Some proxy software may treat `%2F` specially: for instance, Apache, when
|
|
|
|
configured as a reverse-proxy, will reject requests for a path containing
|
|
|
|
configured as a reverse-proxy, will reject requests for a path containing
|
|
|
@ -162,4 +162,4 @@ it feels we should not prioritise consistency of encodings for SS/E2EE developer
|
|
|
|
over the usability of the CS API.
|
|
|
|
over the usability of the CS API.
|
|
|
|
|
|
|
|
|
|
|
|
Therefore, on balance, it seems plausible that changing the format of event IDs
|
|
|
|
Therefore, on balance, it seems plausible that changing the format of event IDs
|
|
|
|
does solve sufficient problems to make it desirable.
|
|
|
|
does solve sufficient problems to make it desirable.
|
|
|
|