社区应用 最新帖子 精华区 社区服务 会员列表 统计排行 银行

  • 10361阅读
  • 1回复

网站URL的不可忽略的注意事项

级别: 管理员
发帖
8532
金币
2762
威望
3231
贡献值
0
元宝
0

URL 设计是 Web 设计中常被忽视的东西,事实上 URL 非常重要,这不仅是一个网页唯一的路径,还涉及到你的站点是否干净,友好。本文讲述 URL 这个司空见惯的Web 元素中包含的大量不应为忽视的知识,准则与最佳实践。需要注意的是 W3C 建议使用 URI 取代 URL 一说

关于URL 的一些准则

一个URL 必须唯一地,永久地代表一个在线对象

URL 的最基本的使命是唯一地代表 Internet 上的一个对象,URL 必须和 Internet 上的对象一对一匹配。然而现实中,这很难实现,我们经常可以通过多个 URL 到达同一个页面,比如, http://mysite.com/product/tv 和 http://mysite.com/product?name=tv,这种情形在现代CMS 中更是比比皆是,针对这个问题,SEO moz 有一篇很好的文章,讲到了如何使用 Canonical URL 机制解决站点中的重复 URL 问题

URL 应该是永久的,这就要求你在站点上线前就非常严谨地规划 URL。如果有一天,你不得不更改 URL,一定使用 HTTP 301 机制,告诉浏览器和搜索引擎,你的那个 URL 所代表的对象,已经搬迁到新地址,这个机制可以保证你旧地址所获得 PR 不会被清零。

尽可能用户友好

这是 URL 设计的根本,你的 URL 应该为最终用户而设计。保持 URL 友好的一个好办法是在保证可读性的同时让它尽可能短。比如 /about 就好过 /about-acme-corp-page,当然,保持简短不能牺牲可读性, /13d2 一类的地址短则短矣,但并不友好。如果要在 Twitter, Facebook 一类的社会媒体网络分享你的 URL,可以使用 Bit.ly 一类的网址缩短工具,但这种工具产生的缩短 URL 并不友好,在 Wordpress 一类的 CMS 中,可以使用 PrettyLink Pro 或 Short URL plugin 一类的可控制的地址缩短插件。

URL 的设计切忌使用一些对用户来说没有意义的内容,比如数据库的 ID 号, /products/23 这样的 URL 地址对用户是极不友好的,应当使用 /products/ballpoint-pen 一类的地址。

保持一致性

站点内的所有 URL 必须保持一致的格式和结构,这样可以为用户带来信任感,如果你必须更改 URL 格式和结构,需要使用 HTTP 301 机制。

可预测的 URL

这也是 URL 一致性的一个表现,如果你的 URL 拥有很好的一致性,用户可以根据 URL 猜测别的内容的 URL,假如 /events/2010/01 指向 2010 年1 月份的日程内容,那

1、/events/2009/01 应当指向 2009 年 1 月的日程。

2、/events/2010 应当指向 2010 年全年的日程。

3、/events/2010/01/21 应当指向2010年1月21日的日程。

URL中的关键词

URL 中应该包含本页重点内容的关键词,比如 /posts/2010/07/02/trip-best-buy-memory-cards 一类的 URL 本身就是对页面内容的反应。在 URL 包含重点内容关键词,也可以提高 SEO 性能。SEO 的一个很重要的原则就是,在 URL 地址中包含内容关键词。

关于 URL 的技术细节:

URL 不应包含 .html, aspx, cfm 一类的后缀

这类信息对最终用户是没有意义的,却占了额外的空间,一个例外是 .atom, .rss, .json 一类的特殊地址,这类地址是有特别的意义的。译者注:在某些虚拟主机式 Web 服务器,这种做法未必现实。

URL 不应包含 WWW 部分

WWW 部分并不包含任何意义,是一个额外的负担,不友好。可以使用 HTTP 301 机制,将 www.domain.com 定向到 domain.com 。

URL 的格式

URL 的格式如下:

domain.com/[key information]/[name]/?[modifiers]

Key information 部分一般代表信息的类型或类别。Modifiers 部分则属于查询字符串范畴,它不应当代表数据结构,应当代表数据的修饰。Key information 部分应当尽可能简短,同时应当表现出一种层级关系,比如 http://domain.com/posts/servers/nginx-ubuntu-10.04,或 http://domain.com/news/tech/2007/11/05/google-announces-android。

Google News 对新闻源有一个有趣的要求,Google 要求新闻源页面的 URL 中必须包含至少 3 位唯一的数字,因为他们会忽略年份数字,因此,应该使用一个5位或5位以上的数字。另外,也应该提供 Google News 站点地图 。如果你想向 Google 提供新闻,必须按这样的结构提供 URL,当然保持一致性,可以预测性也是必需的。

使用小写字符

URL 中所有字符都应使用小写,这更容易阅读。

URL 中包含的行为元素

URL 查询字符串中可能包含一些表示行为的元素,比如 show, delete, edit 等。非破坏性的行为可以体现在 URL 中,破坏性的行为应该使用 POST 。

使用URL 友好字符

在 URL 中体现网页标题的时候,往往会用到一些特殊字符,应当把它们转换为 URL 友好字符:

1、全部大写字符换成小写

2、诸如 é 一类的字符应转换成对应的 e

3、空格使用短划线代替

4、诸如 !, @, #, $, %, ^, &, * 一类的字符应该使用短划线代替

5、双短划线应该使用单短划线代替

6、另外,没有必要的话,避免使用 %20 一类的 URL 逃逸符。

更多观点

Chris Shiflett 建议,可以使用一些类似句子的 URL,如:

chriscoyier.net/authored/digging-into-wordpress/

chriscoyier.net/has-worked-for/chatman-design/

chriscoyier.net/likes/trailer-park-boys

jacobwg.com/thinks/this-post/is/basically-done

译者补充:URL 的长度上限

URL 的最大长度是多少?W3C 的 HTTP 协议 并没有限定,然而,在实际应用中,经过试验,不同浏览器和 Web 服务器有不同的约定:

IE 的 URL 长度上限是 2083 字节,其中纯路径部分不能超过 2048 字节。

Firefox 浏览器的地址栏中超过 65536 字符后就不再显示。

Safari 浏览器一致测试到 80000 字符还工作得好好的。

Opera 浏览器测试到 190000 字符的时候,还正常工作。

Web 服务器:

Apache Web 服务器在接收到大约 4000 字符长的 URL 时候产生 413 Entity Too Large” 错误。

IIS 默认接收的最大 URL 是 16384 字符。

关键词: URL 网站
QQ: 378890364 微信:wwtree(省短信费) 紧急事宜发短信到0061432027638  本站微博:http://t.qq.com/wwtree QQ群:122538123
级别: 管理员
发帖
8532
金币
2762
威望
3231
贡献值
0
元宝
0
只看该作者 沙发  发表于: 2013-06-26
应该知道的关于 URL 编码的知识
本文首先阐述了人们关于统一资源定位符(URL)编码的普遍的误读,其后通过阐明HTTP场景下的URL encoding 来引出我们经常遇到的问题及其解决方案。本文并不特定于某类编程语言,我们在Java环境下阐释问题,最后从Web应用的多个层次描述如何解决URL编码的问题来结尾。
目录


简介
通用 URL语法
HTTP URL语法
URL 语法
URL常见陷阱
使用哪类字符编码?
因片段而异的保留字符集
非你所想的保留字符集
解码以后无法解析的URL
解码以后无法重新编码成相同形式的URL
在Java中正确地处理URL
勿用java.net.URLEncoder或java.net.URLDecoder编解码整个URL
构建URL需要考虑编码每个部份
URI.getPath()无法确保提供结构化的数据
Apache Commons HTTPClient的URI类无法确保总能正确处理
在Web应用程序的每个层次处理URL编码问题
创建URL时总是编码URL
确保你的URL重写过滤器正确处理URLs
正确使用Apache mod-rewrite模块
结论
简介


当我们每天上网冲浪时,有一些技术我们无时无刻不在面对。有数据本身(网页),数据的格式化,能够让我们获取数据的传输机制,以及让Web网络能够真正成为Web的基础及根本:从一页到另一页的链接。这些链接都是URL。


史涛
翻译于 昨天(12:42)
1人顶
顶 翻译的不错哦!
通用URL语法


我敢说每个人在其一生中至少见过一次URL。比如"http://www.google.com",就是一个URL。一个URL是一个统一资源定位器 ,事实上它指向了一个网页(大多数情况下)。实际上,自从1994年的第一版规范开始,URL就有了一个良好定义的结构。
我们能从"http://www.google.com" 这个URL中读出下列详细信息:
Part     Data
Scheme     http
Host address     www.google.com
如果我们看一个更复杂的URL,比如 "https://bob:bobby@www.lunatech.com:8080/file;p=1?q=2#third" 我们就能获取到下列信息:
Part     Data
Scheme     https
User     bob
Password     bobby
Host address     www.lunatech.com
Port     8080
Path     /file
Path parameters     p=1
Query parameters     q=2
Fragment     third
协议 (即scheme,如上面的http和https (安全HTTP)) 定义了URL中其余部分的结构。大多数互联网URL协议 拥有通用的开头,包括用户,密码,主机名和端口,后面才是每个协议具体的部分。这个通用的部分负责处理认证,同时它也有能力知道为了请求数据应该链接到哪儿。


lwei
翻译于 昨天(9:37)
1人顶
顶 翻译的不错哦!
HTTP URL语法


对于HTTP URL (使用http 或 https 协议),URL的scheme描述部分定义了数据的路径(path),后面是可选的query 和 fragment。
path 部分看上去是一个分层的结构,类似于文件系统中文件夹和文件的分层结构。path由"/"字符开始,每一个文件夹由"/"分隔,最后是文件。例如"/photos/egypt/cairo/first.jpg"有四个路径片段(segment):"photos"、"egypt"、"cairo" 和 "first.jpg",可以由此推出:"first.jpg" 文件在文件夹"cairo"中,而"egypt" 文件夹位于web站点的根文件夹"photos"里面。
每一个path片段 可以有可选的 path参数 (也叫 matrix参数),这是在path片段的最后由";"开始的一些字符。每个参数名和值由"="字符分隔,像这样:"/file;p=1",这定义了path片段 "file"有一个 path参数 "p",其值为"1"。这些参数并不常用 — 这得清楚 — 但是它们确实是存在,而且从 Yahoo RESTful API 文档我们能找到很好的理由去使用它们:
Matrix参数可以让程序在GET请求中可以获取部分的数据集。参考数据集的分页。因为matrix参数可以跟任何数据集的URI格式的path片段,它们可以在内部的path片段中被使用。




LinuxQueen
翻译于 昨天(10:22)
1人顶
顶 翻译的不错哦!
在 路径(path)部分之后是 查询 (query)部分,它和 路径 之间由一个“?”隔开, 查询部分包含了一个由“&”分隔开的参数列表,每一个参数由参数名称、“=”号以及参数值组成。比如"/file?q=2"定义了一个 查询参数 "q" ,它的值是"2"。这在提交 HTML表单时,或者当你使用诸如Google搜索等应用时, 用的非常多。
一个HTTP URL的最后部分是一个段落(fragment)部分,用来指向HTML文件中具体的某个部分,而不是整个HTML页面。比如说,当你点击链接时浏览器自动滚屏到某个部分而不是从页面最顶部开始展示,就说明你点击了一个拥有段落部分的URL。


lwei
翻译于 昨天(10:14)
0人顶
顶 翻译的不错哦!
其它翻译版本(1)
URL 语法


http URL 方案最初由 RFC 1738 定义(实际上,在之前的 RFC 1630也有涉及),而在 http URL 方案被重新定义之前,整个 URL 语法就已经由扩展了几次 以适应发展的规范进化为一套 统一资源标识符(Uniform Resource Identifiers 即 URIs)。
对于 URLs 如何拼装,各部分如何分隔有一套语法。例如:"://"分隔方案和主机部分。主机同路径片段部分由"/"分隔,而查询部分紧跟在"?"之后。这意味着有些字符为语法保留。有些为整个URIs保留,而有些则被特定方案保留。所有出现在不应出现位置的 保留符(例如路径片段——以文件名为例——可能包含"?")必须被URL 编码。


Khiyuan
翻译于 昨天(11:01)
0人顶
顶 翻译的不错哦!
其它翻译版本(1)
URL 编码将字符转变成对 URL 解析无意义的无害形式。它将字符转化成为一种特定字符编码的字节序列,然后将字节转换为16进制形式,并将其前面加上"%"。问号的 URL 编码形式为"%3F"。
我们可以将指向 "to_be_or_not_to_be?.jpg"图片的 URL 写成:"http://example.com/to_be_or_not_to_be%3F.jpg",这样就没有人会认为这儿可能由一个查询部分了。
现今多数浏览器显示 URLs 前都会对其解码(将百分号编码字节转回其原本字符),并在获取其网络资源的时候重新编码。这样一来,很多用户从未意识到编码的存在。
另一方面,网页作者,开发者必须明确认识到这一点,因为这里存在着很多陷阱。


Khiyuan
翻译于 昨天(11:25)
0人顶
顶 翻译的不错哦!
URL常见陷阱


如果你正和URL打交道,了解下能够避免的常见陷阱绝对是值得的。现在我们给大家介绍下不仅限于此的一些常见陷阱。
使用哪类字符编码?


URL编码规范并没有定义使用何种字符编码形式去编码字节。一般的ASCII字母数字字符并不需要转义,但是ASCII之外的保留字需要(例如法语单词“nœud”中的"œ")。我们必须提出疑问,应该使用哪类字符编码来编码URL字节。
当然如果只有Unicode的话,这个世界就会清净很多。因为每个字符都包含其中,但是它只是一个集合,或者说是列表如果你愿意,它本身并不是一中编码。Unicode可以使用多种方式进行编码,譬如UTF-8或者UTF-16(也有其它格式),但是问题并没有解决:我们应该使用哪类字符来编码URL(通常也指URI)。
标准并没有定义一个URI应该以何种方式指定其编码,所以其必须从环境信息中进行推导。对于HTTP URL,它可以是HTML页面的编码格式,或HTTP头的。这通常会让人迷惑,也是许多错误的根源。事实上,最新版的URI标准 定义了新的URI scheme将采用UTF-8,host(甚至已有的scheme)也使用UTF-8,这让我更加怀疑:难道host和path真的可以使用不同的编码方式?


史涛
翻译于 昨天(13:17)
0人顶
顶 翻译的不错哦!
每一部分的保留字都是不同。
是的,他们是,是的,他们,是的,他们是。。。
对于一个httpd连接,路径片段部分中的空格被编码为"%20"(不,完全没有"+"),而“+”字符在路径片段部分可以保持不编码。
现在,在查询部分,一个空格可能会被编码为“+”(为了向后兼容:不要试图在URI标准去搜索他)或者“%20”,当作为“+”字符(作为个统配符的结果)会被编译为“%2B”。
这意味着“blue+light blue”字串,如果在路径部分或者查询部分,将会有不同的编码。比如得到"http://example.com/blue+light%20blue?blue%2Blight+blue"这样的编码形式,这样我们不需从语法上分析url结构,就可以推导这个url的整个结构是可能


桔子
翻译于 昨天(14:35)
0人顶
顶 翻译的不错哦!
考虑如下组装URL的Java代码片段
1
String str = "blue+light blue";
2
String url = "http://example.com/" + str + "?" + str;
编码URL并不是为了转义保留字而进行的简单字符迭代,我们需要确切的知道哪个URL部份有哪些保留字,而有针对性的进行编码。
这也意味着URL重写过滤器如果不考虑合适的编码细节而对URL直接进行分段转换通常是有问题的。对URL进行编码而不考虑具体的分段规则是不切实际的。


史涛
翻译于 昨天(11:35)
0人顶
顶 翻译的不错哦!
保留字不是你想象的那样
大多数人不知道"+"在路径部分是被允许的并且特指正号而不是空格。其他类似的有:
"?"在查询部分允许不被转义,
"/"在查询部分允许不被转义,
"="在作为路径参数或者查询参数值以及在路径部分允许不被转义,
":@-._~!$&'()*+,;="等字符在路径部分允许不被转义,
"/?:@-._~!$&'()*+,;="等字符在任何段中允许不被转义。
  这样下面的地址虽然看起来有点混乱:"http://example.com/:@-._~!$&'()*+,=;:@-._~!$&'()*+,=:@-._~!$&'()*+,==?/?:@-._~!$'()*+,;=/?:@-._~!$'()*+,;==#/?:@-._~!$&'()*+,;="
按照上面的规则,其实上是一个合法的地址。
不用奇怪,上面路径可以被解析为:
部分

协议
http
主机
example.com
路径
/:@-._~!$&'()*+,=
路径参数名     :@-._~!$&'()*+,
路径参数值     :@-._~!$&'()*+,==
查询参数名     /?:@-._~!$'()* ,;
查询参数值     /?:@-._~!$'()* ,;==
段     /?:@-._~!$&'()*+,;=


桔子
翻译于 昨天(14:52)
0人顶
顶 翻译的不错哦!
不能分析解码后的URL


URL的语法只在它被解码前是有意义的,一旦解码就可能出现保留字。
例如"http://example.com/blue%2Fred%3Fand+green" 在解码前由如下部分组成:
Part     Value
Scheme     http
Host     example.com
Path segment     blue%2Fred%3Fand+green
Decoded Path segment     blue/red?and+green
这样看来, 我们是在请求一个名为"blue/red?and+green"的文件,而不是一个位于"blue"文件夹下的名为"red?and+green"的文件。
如果我们把它解码为"http://example.com/blue/red?and+green",我们将得到如下部分:
Part     Value
Scheme     http
Host     example.com
Path segment     blue
Path segment     red
Query parameter name     and green
这明显是错误的,所以,对保留字和URL各部分的分析必须在URL解码之前完成。这意味着URL重写过滤器不应当在尝试匹配之前解码URL,当且仅当保留字允许进行URL编码时才可以(有时符合这种情形,有时不符合,这取决于你的应用)。


lwei
翻译于 昨天(15:07)
0人顶
顶 翻译的不错哦!
其它翻译版本(1)
解码后的URL不能被再编码为同样的形式


如果你解码"http://example.com/blue%2Fred%3Fand+green" 为"http://example.com/blue/red?and+green",然后对它进行编码(哪怕使用一个对URL每一部分都很了解的编码器),你将会得到"http://example.com/blue/red?and+green",这是因为它已经是一个有效的URL。它跟我们解码之前的URL非常的不同。
用Java正确处理URL


当你觉得自己已经拿到了URL的黑腰带(柔道中的最高级别--译者注),你将会发现仍有一些Java里特有的、URL相关的陷阱。如果没有一个强大的心脏,你很难正确的处理URL。


lwei
翻译于 昨天(12:50)
0人顶
顶 翻译的不错哦!
不要用java.net.URLEncoder或者java.net.URLDecoder来处理整个URL


不开玩笑。这些类不是用来编码或解码URL的,API文档中清楚的写着:
Utility class for HTML form encoding. This class contains static methods for converting a String to theapplication/x-www-form-urlencodedMIME format. For more information about HTML form encoding, consult the HTML specification.


这不是给URL用的。充其量它类似于查询 部分的编码方式。使用它来编码或解码整个URL是错误的。你肯定以为标准的JDK一定会有一个标准的类来正确的处理URL编码(是这样,只不过是各部分分开处理的),但是要么是压根没有,要么是我们还没有发现。不过,这种臆测导致许多人错用了URLEncoder。


lwei
翻译于 昨天(13:06)
1人顶
顶 翻译的不错哦!
在对每一部分编码之前不要拼装URL


正如我们已经讲过的:完整构建后的URL不能再被编码。
以下面的代码为例:
1
String pathSegment = "a/b?c";
2
String url = "http://example.com/" + pathSegment;
如果"a/b?c" 是一个路径片段,那么不可能把"http://example.com/a/b?c" 转换回之前它的原样,因为它碰巧是一个有效的URL。之前我们已经解释过这一点。
下面是正确的代码:
1
String pathSegment = "a/b?c";
2
String url = "http://example.com/"
3
            + URLUtils.encodePathSegment(pathSegment);
这里我们使用了一个工具类URLUtils,它是我们自己开发的,因为网络上找不到一个详尽的足够快的工具类。上面的代码会带给你正确编码的URL "http://example.com/a%2Fb%3Fc"。
注意,同样的方式也适用于查询子串:
1
String value = "a&b==c";
2
String url = "http://example.com/?query=" + value;
这会给你"http://example.com/?query=a&b==c",这是个有效的URL,而不是我们想得到的"http://example.com/?query=a%26b==c"。


lwei
翻译于 昨天(13:27)
1人顶
顶 翻译的不错哦!
不要期望 URI.getPath() 给你结构化的数据


因为一旦一个URL被解码,句法信息就会丢失,下面这样的代码就是错误的:
1
URI uri = new URI("http://example.com/a%2Fb%3Fc");
2
for(String pathSegment : uri.getPath().split("/"))
3
  System.err.println(pathSegment);
它会先将路径 "a%2Fb%3Fc"解码为 "a/b?c",然后在不应该分割的地方将地址分割为地址片段。
正确的代码使用的是 未解码的路径 :
1
URI uri = new URI("http://example.com/a%2Fb%3Fc");
2

3
for(String pathSegment : uri.getRawPath().split("/"))
4
  System.err.println(URLUtils.decodePathSegment(pathSegment));
注意路径参数仍然存在:如果需要的话再处理它们。


super0555
翻译于 昨天(13:42)
0人顶
顶 翻译的不错哦!
不要期望 Apache Commons HTTPClient的URI类能够正确的做对


Apache Commons HTTPClient 3的 URI 类使用了Apache Commons Codec的URLCodec来做 URL编码, 正如 API文档提到的 它是有问题的,因为它犯了和使用java.net.URLEncoder同样的错误。它不但使用了错误的编码器,还错误的 按照每一部分都具有同样的预定设置进行解码。
在web应用的每一层修复URL编码问题


近来我们已经被动修复了许多应用中的URL编码问题。从在Java中支持它,到低层次的URL重写。这里我们会列出一些必要的修改。
总是在创建的时候进行URL编码


在我们的 HTML文件中,我们将所有出现:
1
var url = "#{vl:encodeURL(contextPath + '/view/' + resource.name)}";
的地方替换为:
1
var url = "#{contextPath}/view/#{vl:encodeURLPathSegment(resource.name)}";
查询参数也是类似的。


super0555
翻译于 昨天(14:02)
0人顶
顶 翻译的不错哦!
确保你的URL-rewrite过滤器正确的处理网址
Url 重写过滤器是一个重写过滤器,我们在seam中用于转化漂亮的地址去应用依赖的网址。
例如,我们用它把http://beta.visiblelogistics.com/view/resource/FOO/bar转化为http://beta.visiblelogistics.com/resources/details.seam?owner=FOO&name=bar
很明显,这个过程包含了一些字符串从一个地址到另一个地址,这意味着我们要从路径部分解码并且把它重新编码为另一个查询值部分。
我们起初的规则,如下所示:
1
<urlrewrite decode-using="utf-8">
2
<rule>
3
  <from>^/view/resource/(.*)/(.*)$</from>
4
  <to encode="false">/resources/details.seam?owner=$1&name=$2</to>
5
</rule>
6
</urlrewrite>
从这我们可以看到在重写过滤器中只有两种方法处理网址重写:每一个的网址先被解码去做规则匹配(<to>模式),或者它不可用,所有规则去处理解码。在我们看来后者是比较好的选择,特别是当你要移动网址部分周围,或者想去包含URL解码路径分隔符的匹配路径部分时候。


桔子
翻译于 昨天(15:30)
0人顶
顶 翻译的不错哦!
在替换模式中(<to>模式)你可以使用内建的函数escape(String)和unescape(String)处理网站转码和解码。
在撰写这个文章的时候,Url Rewrite Filter Beta 3.2有一些bugs,限制住我们提高URL-correctness:
网址解码使用java.net.URLDecoder(这是错误的),
escape(String)和unescape(String)内建函数使用java.net.URLDecoder和java.net.URLEncoder(不够强大,只能用于这个查询字串,所有的"&"或者"="不被转码)。
We therefore made a big patch fixing a few issues like URL decoding, and adding the inline functionsescapePathSegment(String)andunescapePathSegment(String).
我们因此做了一个大修正补丁,用于修正诸如网址解码问题以及增加内建函建escapePathSegment(String) 和 unescapePathSegment(String)


桔子
翻译于 昨天(15:42)
0人顶
顶 翻译的不错哦!
我们现在可以这样写,几乎不会有错误
1
<urlrewrite decode-using="null">
2
<rule>
3
  <from>^/view/resource/(.*)/(.*)$</from>
4
  <-- Line breaks inserted for readability -->
5
  <to encode="false">/resources/details.seam
6
                     ?owner=${escape:${unescapePath:$1}}
7
                     &name=${escape:${unescapePath:$2}}</to>
8
</rule>
9
</urlrewrite>
唯一可能出问题的地方是由于我们的补丁还不能解决以下的问题:
内建的escaping/unescaping函数应能只能编码,这已经做为下一个补丁(已经做完了),或者能从http请求来确定(还不支持),
oldescape(String)和unescape(String)内建函数被保留了,并且仍然调用java.net.URLDecoder,而这个包在由于没有解决"&"和"="的问题,所以仍然有问题,
我需要增加更多的局部特定的编码和解码函数,
我们需要增加一个方法去鉴别per-rule解码行为,对照全局在<urlrewrite>。
我们一有时间,我们就会发布第二个补丁。


桔子
翻译于 昨天(16:01)
0人顶
顶 翻译的不错哦!
正确使用Apache mod-rewrite
  Apache mod-rewrite是一个Apache Web服务器的网址重写模块。例如用它来把   http://beta.visiblelogistics.com/foo 的流量代理到http://our-internal-server:8080/vl/foo
这是最后的要修正的事情,就像是Url Rewrite Filter,他默认解码网址给我们,并且从新编码重写过得网址给我们,这其实上是错误的,因为"解码的网址不能被重新编码"。
有一种方法可以避免这种行为,至少在我们的案例中我们没有转化一个网址部分到另一个网址,例如,我们不需要解码一个路径部分并且重新编码它到一个查询部分:没有加码也没有重编码。
我们通过THE_REQUEST来网址匹配来完成工作。他是完全的HTTP请求(包括HTTP方法和版本)联合解码。我们只要取host后面的URL部分,改变host和预设的/v/前缀和tada
...


# This is required if we want to allow URL-encoded slashes a path segment
AllowEncodedSlashes On


# Enable mod-rewrite
RewriteEngine on


# Use THE_REQUEST to not decode the URL, since we are not moving
# any URI part to another part so we do not need to decode/reencode


RewriteCond %{THE_REQUEST} "^[a-zA-Z]+ /(.*) HTTP/\d\.\d$" RewriteRule ^(.*)$ http://our-internal-server:8080/vl/%1 [P,L,NE]


桔子
翻译于 昨天(16:19)
0人顶
顶 翻译的不错哦!
结论


我希望阐明一些URL技巧和常见的错误。简而言之,能把它说明白就够了,但这不是一些人想象的那样简单的。我们展示了java常见的错误和一个web 应用部署的整个过程。现在每个读者都应该是一个URL专家了,并且我们希望不要在看见相关bugs再出现。请求SUN公司,请为URL encoding/decoding逐项的增加标准支持
QQ: 378890364 微信:wwtree(省短信费) 紧急事宜发短信到0061432027638  本站微博:http://t.qq.com/wwtree QQ群:122538123
描述
快速回复

您目前还是游客,请 登录注册
批量上传需要先选择文件,再选择上传