关于The valid characters are defined in RFC 7230 and RFC 3986问题

简介: 建议从目前的角度出发使用第三种方式降低tomcat版本就可以了,如果从长远出发的话,建议遵循RFC 7230 and RFC 3986规范,对于非保留字字符(json格式的请求参数)做转义操作。

关于The valid characters are defined in RFC 7230 and RFC 3986问题


一、背景


最近在某详情页面需要使用到地图相关API,但不能直接写入页面,会和原页面样式冲突,故嵌入了一个单独的html,奈何在IE下(客户多数使用IE)并不是很友好,一直找不到页面。经过各种search(百度,Google,Stack Overflow。。。)找到了问题的根本所在。


二、出现原因

20180806193152804.png

摘自网友:


①  在tomcat 8.0.35之后 ,tomcat对url的参数做了比较规范的限制,必须按照RFC 7230 and RFC 3986规范,对于非保留字字符,如果不做转义处理,一律都会报The valid characters are defined in RFC 7230 and RFC 3986 错误


②  RFC3986文档规定,Url中只允许包含英文字母(a-zA-Z)、数字(0-9)、-_.~4个特殊字符以及所有保留字符。


RFC3986中指定了以下字符为保留字符:


image.png


还有一些字符,当他们直接放在Url中的时候,可能会引起解析程序的歧义。这些字符被视为不安全字符,原因有很多。


不安全字符有:


->空格    Url在传输的过程,或者用户在排版的过程,或者文本处理程序在处理Url的过程,都有可能引入无关紧要的空格,或者将那些有意义的空格给去掉


->引号以及<>    引号和尖括号通常用于在普通文本中起到分隔Url的作用


-># 通常用于表示书签或者锚点


->% 百分号本身用作对不安全字符进行编码时使用的特殊字符,因此本身需要编码


->{}|\^[]`~    某一些网关或者传输代理会篡改这些字符


此处就是json格式的参数在地址栏传递过程中转义出了问题,一半地址中传递的参数含有中文也遇到了此异常。可以对字符串进行编码解决此问题。js编码的函数有: escape,encodeURI,encodeURIComponent,相应3个解码函数:unescape,decodeURI,decodeURIComponent 。


其中escape()除了 ASCII 字母、数字和特定的符号外,对传进来的字符串全部进行转义编码,因此如果想对URL编码,最好不要使用此方法,而encodeURI()用于编码整个URI,因为URI中的合法字符都不会被编码转换。encodeURIComponent方法在编码单个URIComponent(指请求参数)应当是最常用的,它可以讲参数中的中文、特殊字符进行转义,而不会影响整个URL。


三、解决方案


由于我是将父页面的值传递给子页面,子页面再将父页面路径值按 “&” 符号进行切割,所以我只需要更改拼接符即可(不推荐),但这种并非通用而长久之计,可以有以下几种解决方案:


①   换了个低版本的tomcat


②   遵循7230 and RFC 3986规范,对于非保留字字符做转义操作


③   使用保留字字符


④   将json数据进行urlencode编码


建议从目前的角度出发使用第三种方式降低tomcat版本就可以了,如果从长远出发的话,建议遵循RFC 7230 and RFC 3986规范,对于非保留字字符(json格式的请求参数)做转义操作。

目录
相关文章
|
26天前
|
应用服务中间件
The valid characters are defined in RFC XXXX
The valid characters are defined in RFC XXXX
12 0
Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC
Invalid character found in the request target. The valid characters are defined in RFC 7230 and RFC
|
7月前
|
编解码 前端开发 JavaScript
IE上的 The valid characters are defined in RFC 7230 and RFC 3986 坑的解决方法
IE上的 The valid characters are defined in RFC 7230 and RFC 3986 坑的解决方法
90 2
|
8月前
|
自然语言处理 知识图谱
ACL2022 Document-Level Event Argument Extraction via Optimal Transport
事件论元抽取(EAE)是事件抽取的子任务之一,旨在识别每个实体在特定事件触发词中的作用。尽管先前的工作在句子级EAE方面取得了成功,但对文档级的探索较少。
72 0
|
8月前
|
机器学习/深度学习 自然语言处理 算法
ACL 2019 - AMR Parsing as Sequence-to-Graph Transduction
我们提出了一个基于注意力的模型,将AMR解析视为序列到图的转导。与大多数依赖于预训练的对齐器、外部语义资源或数据扩充的AMR解析器不同
112 0
ACL 2019 - AMR Parsing as Sequence-to-Graph Transduction
|
8月前
|
机器学习/深度学习 数据挖掘
ACL2023 - An AMR-based Link Prediction Approach for Document-level Event Argument Extraction
最近的工作引入了用于文档级事件论元提取(文档级EAE)的抽象语义表示(AMR),因为AMR提供了对复杂语义结构的有用解释,并有助于捕获长距离依赖关系
99 0
|
11月前
|
算法 安全 Unix
翻译[RFC6238] TOTP: Time-Based One-Time Password Algorithm
翻译[RFC6238] TOTP: Time-Based One-Time Password Algorithm
104 0
005. how is RFC to backend determined - maintenance view IWFNDV_MGDEAM
005. how is RFC to backend determined - maintenance view /IWFND/V_MGDEAM Created by Wang, Jerry, last modified on Dec 26, 2014
73 0
005. how is RFC to backend determined - maintenance view IWFNDV_MGDEAM
RFC and session issue - why we should use DESTINATION NONE?
RFC and session issue - why we should use DESTINATION NONE?
118 0
RFC and session issue - why we should use DESTINATION NONE?
An RFC destination could not be specified for the logical system QI3CLNT504
An RFC destination could not be specified for the logical system QI3CLNT504
An RFC destination could not be specified for the logical system QI3CLNT504