URL定义了用户所需的特定资源，它位于何处以及如何获取它。

url的方案，规定了以是什么样的协议访问服务器。方案组件必须以一个字母符号开始， 由第一个“:” 符号将其与 URL 的其余部分分隔开来。 方案名是大小写无关的。

端口组件标识了服务器正在监听的网络端口。

字符“@” 将用户和密码组件与 URL 的其余部分分隔开来，用户名（anonymous） 和密码（my_passwd）， 两者之间由字符“:” 分隔。

URL 的路径组件说明了资源位于服务器的什么地方

URL 的查询组件和标识网关资源的

URL 路径组件一起被发送给网关资源。 基本上可以将网关当作访问其他应用程序的访问点

服务器处理的是整个对象， 因此 URL 片段仅由客户端使用

相对URL

相对 URL 为保持一组资源（比如一些 HTML 页面） 的可移植性提供了一种便捷方式。

基础URL

• 在资源中显式提供

有些资源会显式地指定基础 URL。 比如， HTML 文档中可能会包含一个定义了基础 URL 的 HTML 标记 ， 通过它来转换那个 HTML 文档中的所有相对

URL。

• 封装资源的基础 URL

如果在一个没有显式指定基础 URL 的资源中发现了一个相对 URL， 可以将它所属资源的 URL 作为基础（如例中所示）。

• 没有基础 URL

在某些情况下， 没有基础 URL。 这通常意味着你有一个绝对 URL； 但有时可能只是一个不完整或损坏了的 URL。

编码

URL 的每个组件都会有自己的安全 / 不安全字符， 哪些字符是安全 / 不安全的 与方案有关， 因此只有从用户那里接收 URL 的应用程序才能够判断需要对哪些字符进行编码。

在实际应用中， 有些应用程序可能会假定不对安全字符进行编码， 如果对所有的字符都进行编码话可能会产生一些奇怪的破坏性行为。

有些人会恶意地对额外的字符进行编码， 以绕过那些对 URL 进行模式匹配 的应用程序——比如， Web 过滤程序。 对安全的 URL 组件进行编码会使模式匹配程序无法识别出它们所要搜寻的模式。

方案

方案 https 与方案 http 是一对。 唯一的区别在于 方案 https 使用了网景的SSL， SSL 为HTTP 连接提供了端到端的加密机制。 其语法与 HTTP 的语法相同， 默认端口为 443。

永久统一资源定位符（persistent uniform resource locators， PURL） 是用 URL 来实现 URN 功能的一个例子。 其基本思想是在搜索资源的过程中引入另一个中间层，通过一个中间资源定位符（resource locator） 服务器对资源的实际 URL 进行登记和跟踪。 客户端可以向定位符请求一个永久 URL， 定位符可以以一个资源作为响应，将客户端重定向到资源当前实际的 URL 上去。