html链接regard,4.8 Links — HTML5

When a user downloads a hyperlink created by an

element, the user agent must run the following steps:

Resolve the URL given by the

If resolving the URL fails, the user agent

may report the error to the user in a user-agent-specific manner, may

navigate to an error page to report the error, or may

ignore the error and do nothing. In either case, the user agent must abort these steps.

Otherwise, let URL be the resulting absolute

URL.

In the case of server-side image maps, append the URL.

Return to whatever algorithm invoked these steps and continue

these steps asynchronously.

Fetch URL and handle the resulting resource

as a download.

When a user agent is to handle a resource obtained from a fetch algorithm as

a download, it should provide the user with a way to save the resource for later use, if a

resource is successfully obtained; or otherwise should report any problems downloading the file to

the user.

If the user agent needs a file name for a resource being handled as a download, it

should select one using the following algorithm.

This algorithm is intended to mitigate security dangers involved in downloading

files from untrusted sites, and user agents are strongly urged to follow it.

Let filename be the void value.

If the resource has a Content-Disposition

header, that header specifies the attachment disposition type, and the

header includes file name information, then let filename have the value

specified by the header, and jump to the step labeled sanitize below. [RFC6266]

Let interface origin be the origin of the

download or

navigate action resulting in the download was initiated, if any.

Let resource origin be the origin of the URL of the

resource being downloaded, unless that URL's scheme

component is data, in which case let resource origin be

the same as the interface origin, if any.

If there is no interface origin, then let trusted

operation be true. Otherwise, let trusted operation be true if resource origin is the same origin as interface

origin, and false otherwise.

If trusted operation is true and the resource has a Content-Disposition header and that header includes file

name information, then let filename have the value specified by the header,

and jump to the step labeled sanitize below. [RFC6266]

If the download was not initiated from a hyperlink created by an

hyperlink from

which it was initiated did not have a no proposed

file name.

Let proposed filename have the value of the hyperlink that initiated the download at the time the download was

initiated.

If trusted operation is true, let filename have

the value of proposed filename, and jump to the step labeled sanitize

below.

If the resource has a Content-Disposition

header and that header specifies the attachment disposition type, let filename have the value of proposed filename, and jump to the

step labeled sanitize below. [RFC6266]

No proposed file name: If trusted operation is true, or if the

user indicated a preference for having the resource in question downloaded, let filename have a value derived from the URL of the resource in a

user-agent-defined manner, and jump to the step labeled sanitize below.

Act in a user-agent-defined manner to safeguard the user from a potentially hostile

cross-origin download. If the download is not to be aborted, then let filename be set to the user's preferred file name or to a file name selected by

the user agent, and jump to the step labeled sanitize below.

If the algorithm reaches this step, then a download was begun from a different origin than

the resource being downloaded, and the origin did not mark the file as suitable for

downloading, and the download was not initiated by the user. This could be because a

This could be dangerous, because, for instance, a hostile server could be trying to get a

user to unknowingly download private information and then re-upload it to the hostile server,

by tricking the user into thinking the data is from the hostile server.

Thus, it is in the user's interests that the user be somehow notified that the resource in

question comes from quite a different source, and to prevent confusion, any suggested file name

from the potentially hostile interface origin should be ignored.

Sanitize: Optionally, allow the user to influence filename. For

example, a user agent could prompt the user for a file name, potentially providing the value of

filename as determined above as a default value.

Adjust filename to be suitable for the local file system.

For example, this could involve removing characters that are not legal in

file names, or trimming leading and trailing whitespace.

If the platform conventions do not in any way use extensions to determine the types of file on the file system,

then return filename as the file name and abort these steps.

Let claimed type be the type given by the resource's Content-Type metadata, if any is known. Let named

type be the type given by filename's extension, if any is known. For the purposes of this step, a

type is a mapping of a MIME type to an extension.

If named type is consistent with the user's preferences (e.g. because

the value of filename was determined by prompting the user), then return filename as the file name and abort these steps.

If claimed type and named type are the same type

(i.e. the type given by the resource's Content-Type metadata is

consistent with the type given by filename's extension), then return filename as the file

name and abort these steps.

If the claimed type is known, then alter filename to

add an extension corresponding to claimed

type.

Otherwise, if named type is known to be potentially dangerous (e.g. it

will be treated by the platform conventions as a native executable, shell script, HTML

application, or executable-macro-capable document) then optionally alter filename to add a known-safe extension

(e.g. ".txt").

This last step would make it impossible to download executables, which might not

be desirable. As always, implementors are forced to balance security and usability in this

matter.

Return filename as the file name.

For the purposes of this algorithm, a file extension

consists of any part of the file name that platform conventions dictate will be used for

identifying the type of the file. For example, many operating systems use the part of the file

name following the last dot (".") in the file name to determine the type of

the file, and from that the manner in which the file is to be opened or executed.

User agents should ignore any directory or path information provided by the resource itself,

its URL, and any