From 9dcf2d6a2805e4c81b5c04af71034a10cb68282a Mon Sep 17 00:00:00 2001 From: Hubert Chathi Date: Mon, 1 Apr 2019 00:43:31 +0100 Subject: [PATCH] Update proposals/1884-replace-slashes-in-event_ids.md Co-Authored-By: ara4n --- proposals/1884-replace-slashes-in-event_ids.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/1884-replace-slashes-in-event_ids.md b/proposals/1884-replace-slashes-in-event_ids.md index 9c3b7ea75..ae2c0e948 100644 --- a/proposals/1884-replace-slashes-in-event_ids.md +++ b/proposals/1884-replace-slashes-in-event_ids.md @@ -27,7 +27,7 @@ of reasons: * Even if client implementations do remember to URL-encode their parameters, they may not do it correctly: many URL-encoding implementations may be 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 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. Therefore, on balance, it seems plausible that changing the format of event IDs -does solve sufficient problems to make it desirable. \ No newline at end of file +does solve sufficient problems to make it desirable.