我正在从另一台主机检索页面,然后使用数据库中的数据初始化该表单,然后再将其发送给用户.
我需要将URL href和src属性设置为绝对,以便浏览器从正确的位置加载它们.
我是否可以设置HTTP标头以在不修改HTML的情况下实现此目的？
根据W3C上的HTML和URL:
用户代理应根据[RFC1808]计算用于解析相对URL的基本URL .以下是[RFC1808]如何应用于HTML 的摘要.用户代理应根据以下优先级(最高优先级到最低优先级)计算基本URL:
基本URL由
BASE元素设置.基本URL由HTTP标头给出(参见[RFC2068]).
默认情况下,基本URL是当前文档的URL.
此外,
OBJECT和APPLET元素定义的属性优先于BASE元素设置的值.有关这些元素的特定URL问题的详细信息,请参阅这些元素的定义.
RFC 2068是HTTP 1.1的原始规范.它定义了标题Content-Base和Content-Location标题,用于指定实体的基本URL,用于解析实体中的相对URL:
14.11 Content-Base
The Content-Base entity-header field may be used to specify the base
URI for resolving relative URLs within the entity. This header field
is described as Base in RFC 1808, which is expected to be revised.
Content-Base = "Content-Base" ":" absoluteURI
If no Content-Base field is present, the base URI of an entity is
defined either by its Content-Location (if that Content-Location URI
is an absolute URI) or the URI used to initiate the request, in that
order of precedence. Note, however, that the base URI of the contents
within the entity-body may be redefined within that entity-body.
14.15 Content-Location
The Content-Location entity-header field may be used to supply the
resource location for the entity enclosed in the message. In the case
where a resource has multiple entities associated with it, and those
entities actually have separate locations by which they might be
individually accessed, the server should provide a Content-Location
for the particular variant which is returned. In addition, a server
SHOULD provide a Content-Location for the resource corresponding to
the response entity.
Content-Location = "Content-Location" ":"
( absoluteURI | relativeURI )
If no Content-Base header field is present, the value of Content-
Location also defines the base URL for the entity (see section
14.11).
The Content-Location value is not a replacement for the original
requested URI; it is only a statement of the location of the resource
corresponding to this particular entity at the time of the request.
Future requests MAY use the Content-Location URI if the desire is to
identify the source of that particular entity.
A cache cannot assume that an entity with a Content-Location
different from the URI used to retrieve it can be used to respond to
later requests on that Content-Location URI. However, the Content-
Location can be used to differentiate between multiple entities
retrieved from a single requested resource, as described in section
13.6.
If the Content-Location is a relative URI, the URI is interpreted
relative to any Content-Base URI provided in the response. If no
Content-Base is provided, the relative URI is interpreted relative to
the Request-URI.
RFC 2068已过时,由RFC 2616取代,后者是目前大多数Web服务器实现的最常见的HTTP 1.1规范.它Content-Base完全从HTTP 1.1规范中删除标头,并稍微重新定义以下语义Content-Location:
14.14 Content-Location
The Content-Location entity-header field MAY be used to supply the
resource location for the entity enclosed in the message when that
entity is accessible from a location separate from the requested
resource's URI. A server SHOULD provide a Content-Location for the
variant corresponding to the response entity; especially in the case
where a resource has multiple entities associated with it, and those
entities actually have separate locations by which they might be
individually accessed, the server SHOULD provide a Content-Location
for the particular variant which is returned.
Content-Location = "Content-Location" ":"
( absoluteURI | relativeURI )
The value of Content-Location also defines the base URI for the
entity.
The Content-Location value is not a replacement for the original
requested URI; it is only a statement of the location of the resource
corresponding to this particular entity at the time of the request.
Future requests MAY specify the Content-Location URI as the request-
URI if the desire is to identify the source of that particular
entity.
A cache cannot assume that an entity with a Content-Location
different from the URI used to retrieve it can be used to respond to
later requests on that Content-Location URI. However, the Content-
Location can be used to differentiate between multiple entities
retrieved from a single requested resource, as described in section
13.6.
If the Content-Location is a relative URI, the relative URI is
interpreted relative to the Request-URI.
The meaning of the Content-Location header in PUT or POST requests is
undefined; servers are free to ignore it in those cases.
值得注意的是," Content-Location的值也定义了实体的基URI ",此时仍然适用.
展望未来,RFC 2616已被RFC 7230-7235废弃(尚未广泛实施).特别是,RFC 7231完全重新定义了以下语义Content-Location:
3.1.4.2. Content-Location
The "Content-Location" header field references a URI that can be used
as an identifier for a specific resource corresponding to the
representation in this message's payload. In other words, if one
were to perform a GET request on this URI at the time of this
message's generation, then a 200 (OK) response would contain the same
representation that is enclosed as payload in this message.
Content-Location = absolute-URI / partial-URI
The Content-Location value is not a replacement for the effective
Request URI (Section 5.5 of [RFC7230]). It is representation
metadata. It has the same syntax and semantics as the header field
of the same name defined for MIME body parts in Section 4 of
[RFC2557]. However, its appearance in an HTTP message has some
special implications for HTTP recipients.
If Content-Location is included in a 2xx (Successful) response
message and its value refers (after conversion to absolute form) to a
URI that is the same as the effective request URI, then the recipient
MAY consider the payload to be a current representation of that
resource at the time indicated by the message origination date. For
a GET (Section 4.3.1) or HEAD (Section 4.3.2) request, this is the
same as the default semantics when no Content-Location is provided by
the server. For a state-changing request like PUT (Section 4.3.4) or
POST (Section 4.3.3), it implies that the server's response contains
the new representation of that resource, thereby distinguishing it
from representations that might only report about the action (e.g.,
"It worked!"). This allows authoring applications to update their
local copies without the need for a subsequent GET request.
If Content-Location is included in a 2xx (Successful) response
message and its field-value refers to a URI that differs from the
effective request URI, then the origin server claims that the URI is
an identifier for a different resource corresponding to the enclosed
representation. Such a claim can only be trusted if both identifiers
share the same resource owner, which cannot be programmatically
determined via HTTP.
o For a response to a GET or HEAD request, this is an indication
that the effective request URI refers to a resource that is
subject to content negotiation and the Content-Location
field-value is a more specific identifier for the selected
representation.
o For a 201 (Created) response to a state-changing method, a
Content-Location field-value that is identical to the Location
field-value indicates that this payload is a current
representation of the newly created resource.
o Otherwise, such a Content-Location indicates that this payload is
a representation reporting on the requested action's status and
that the same report is available (for future access with GET) at
the given URI. For example, a purchase transaction made via a
POST request might include a receipt document as the payload of
the 200 (OK) response; the Content-Location field-value provides
an identifier for retrieving a copy of that same receipt in the
future.
A user agent that sends Content-Location in a request message is
stating that its value refers to where the user agent originally
obtained the content of the enclosed representation (prior to any
modifications made by that user agent). In other words, the user
agent is providing a back link to the source of the original
representation.
An origin server that receives a Content-Location field in a request
message MUST treat the information as transitory request context
rather than as metadata to be saved verbatim as part of the
representation. An origin server MAY use that context to guide in
processing the request or to save it for other uses, such as within
source links or versioning metadata. However, an origin server MUST
NOT use such context information to alter the request semantics.
For example, if a client makes a PUT request on a negotiated resource
and the origin server accepts that PUT (without redirection), then
the new state of that resource is expected to be consistent with the
one representation supplied in that PUT; the Content-Location cannot
be used as a form of reverse content selection identifier to update
only one of the negotiated representations. If the user agent had
wanted the latter semantics, it would have applied the PUT directly
to the Content-Location URI.
最重要的是,RFC 7231 还声明:
Appendix B. Changes from RFC 2616 ... The definition of Content-Location has been changed to no longer affect the base URI for resolving relative URI references, due to poor implementation support and the undesirable effect of potentially breaking relative links in content-negotiated resources. (Section 3.1.4.2) ...
所以,在回答被问到的问题时:
从RFC 2616开始,答案是肯定的,Content-Location用于在HTTP级别指定实体的基本URL.
从RFC 7231开始,答案为NO,Content-Location不能再用于指定实体的基本URL.
AFAIK,自RFC 7231起,未定义新的或现有的HTTP标头来恢复基本URL行为.因此,不再有HTTP标头可用于指定基本URL.它只能由实体本身指定,如果它需要与实体的请求URL不同.
HTTP没有这样的功能.但您可以使用HTML的BASE元素设置基本URL,如:
京公网安备 11010802040832号 | 京ICP备19059560号-6 