HTTP URL 路径中分隔符的最佳实践
在 HTTP URL 路径中使用各种标点符号是否不明智？我正在为 API 定义资源 URL。这些资源 URL 必须由各种客户端和中间件访问、存储和传输，因此重要的是它们不包含可能导致问题的字符。
RFC 3986，第 2.2 节。 “保留字符” 将以下字符指定为子分隔符： !
RFC 3986，第 2.2 节。 “保留字符” 将以下字符指定为子分隔符： !$&'()*+,;=
amp;'()*+,;=在 HTTP 方案的 URL 路径中任意使用这些字符是否非法？
即使它们根据标准是合法的，但其中是否有很高的机会因不合规的软件而导致现实世界的互操作性问题？
您之前在广泛部署的 API 中是否使用过任何特定的子分隔符而没有出现问题（这将提供证据证明您使用的子分隔符是安全的）？
动机是我们需要界定不具有分层语义的键值对。我们正在考虑这样做：http://doriantaylor.com/policy/http- url-路径-参数-语法 。但是，如果这可能是一个问题，我们将执行 http://example.com /key1/value1/key2/value2
谢谢
Would it be unwise to use various punctuation characters in an HTTP URL path? I am in the process of defining resource URLs for an API. These resource URLs will have to be accessed, stored, and transmitted by a wide variety of clients and middleware, so it is important that they do not contain characters that are likely to cause issues.
RFC 3986, section 2.2. "Reserved Characters" specifies the following characters as sub-delims: !$&'()*+,;=
Are any of these illegal for arbitrary use within URL paths in the HTTP scheme?
Even if they are legal according to the standards, do any of these have a high chance of causing real-world interoperability problems due to non-compliant software?
Are there any specific sub-delims that you have previously used without issue in a widely-deployed API (this would provide evidence that the ones you used are safe)?
The motivation is that we need to delimit key-value pairs which do not have hierarchical semantics. We are considering doing this: http://doriantaylor.com/policy/http-url-path-parameter-syntax . However, if this is likely to be a problem, we will just do http://example.com/key1/value1/key2/value2
thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
无论你走哪条路，都要坚定不移；即使指定了版本，更改 API 也可能会出现问题。同一资源有多个位置是一个坏主意 - 应该有一个规范位置。虽然理论上您可以使用 HTTP 301 重定向，但如果您担心兼容性，最好避免使用。
多里安泰勒集方案看起来合理（并且完全合法），并且不应该给任何系统（或任何没有很大缺陷的系统）带来任何兼容性问题。
如果您的 URL 需要用作新 URL 中的参数，则正斜杠和等号必须为 百分比编码，但这对于标准查询字符串 (
?&=) 和您建议的替代方案以及://都是如此，如果协议已包含在内。显然，如果您想在值中使用;,=您将需要对它们进行编码。我能看到的唯一可能的问题是，您的 URL 是否存储在 CSV 中，但 CSV 库很常见，并且对特殊字符的引用也有明确定义。
Whichever way you go, be sure of it; changing APIs can be problematic, even with a version specified. It's a bad idea to have multiple locations for the same resource - there should be one canonical location. While in theory you can use a HTTP 301 redirect, if you are concerned about compatibility it's best avoided.
The Dorian Taylor set scheme looks sensible (and completely legal) and should not give any compatibility issues with any system (or any that isn't hugely buggy).
If your URL needs to be used as a parameter in a new URL the forward slash and equals will have to be percent encoded, but that's true for both a standard query string (
?&=) and your proposed alternative, as well as the://if the protocol is included. Obviously, if you want to use;,=in your values you will need to encode them.The only possible issue I can see is if your URLs are stored in a CSV, but CSV libraries are common and quoting special characters is well defined.