英文:
Escape exclamation mark in http request
问题
我有一个URL,像这样:
http://app.chat.com/avert!Callbcak.htm
我使用golang创建了请求:
req, _ := http.NewRequest("GET", "http://app.chat.com/avert!Callbcak.htm", nil)
fmt.Printf("%v\n", req.URL.String())
结果是
http://app.chat.com/avert%21Callbcak.htm
这个URL无法正常工作,网站需要未转义的感叹号。
我该如何正确请求这个URL?
英文:
I have a URL like
http://app.chat.com/avert!Callbcak.htm
to request.
I created the request with golang
req, _ := http.NewRequest("GET", "http://app.chat.com/avert!Callbcak.htm", nil)
fmt.Printf("%v\n", req.URL.String())
result is
http://app.chat.com/avert%21Callbcak.htm
which is not going to work, the website needs URL that exclamation mark not escaped.
How can I request that URL correctly?
答案1
得分: 1
终于我在这里找到了答案这里
在发送请求之前,我对请求进行了处理:
func (s *Sender) regulateRequestURL(req *http.Request) {
if strings.Contains(req.URL.Path, "!") {
req.URL.Opaque = fmt.Sprintf("//%s%s", req.URL.Host, req.URL.Path)
}
}
英文:
finally I found answer here
I process the request before sending:
func (s *Sender) regulateRequestURL(req *http.Request) {
if strings.Contains(req.URL.Path, "!") {
req.URL.Opaque = fmt.Sprintf("//%s%s", req.URL.Host, req.URL.Path)
}
}
答案2
得分: 0
从https://www.rfc-editor.org/rfc/rfc3986
第2节关于字符的部分已经重写,以解释哪些字符是保留字符,何时保留这些字符以及为什么保留这些字符,即使它们在通用语法中不被用作分隔符。通常不安全解码的标记字符,包括感叹号("!")、星号("*")、单引号("'")以及开括号和闭括号("("和")"),已被移动到保留集中,以明确保留字符和非保留字符之间的区别,并希望能回答方案设计者最常见的问题。同样,关于百分号编码字符的部分已经重写,现在URI规范化器被授权解码任何百分号编码的八位字节。
这意味着!
是一个不幸的分隔符选择,因为尽管语法允许在segment
中使用它(作为pchar
非终结符的一部分),但它也是reserved
非终结符的一部分。
根据我阅读的RFC,对于!
的保留性在使用的上下文中有些模棱两可。
转义该字符似乎是最安全的假设,因为接收者被“授权解码百分号编码的八位字节”。您应该考虑使用另一个分隔符或在端点上解码实体。
英文:
From https://www.rfc-editor.org/rfc/rfc3986
> Section 2, on characters, has been rewritten to explain what
> characters are reserved, when they are reserved, and why they are
> reserved, even when they are not used as delimiters by the generic
> syntax. The mark characters that are typically unsafe to decode,
> including the exclamation mark ("!"), asterisk ("*"), single-quote
> ("'"), and open and close parentheses ("(" and ")"), have been moved
> to the reserved set in order to clarify the distinction between
> reserved and unreserved and, hopefully, to answer the most common
> question of scheme designers. Likewise, the section on
> percent-encoded characters has been rewritten, and URI normalizers
> are now given license to decode any percent-encoded octets
This means that !
is an unfortunate choice of a separator because although the grammar allows its use in segment
(as part of the pchar
non-terminal) it is also a part of the reserved
non-terminal.
As I read it the RFC is slightly ambivalent about !
reservedness, depending upon the context in which it is used.
Escaping the character seems the most safe assumption to make since the recipient is "licenced to decode the percent-encoded octet". You should consider using another separator or decoding the entity on the endpoint.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论