Appendix B: Log message reference

This section lists messages that you may find in the policy file log, crossdomain.xml. As detailed in the section on logging, some of these messages are prefixed with the designation [strict], meaning that they indicate immediate issues in Phase 1, rather than warnings of impending issues for Phase 2. See the section on immediate issues.

SWF loading

Root-level SWF loaded: (URL).

A top-level SWF file from the indicated URL has been loaded. This is usually the first message in the log, and if you have enabled append-mode logging, you may see it more than once. This message helps you put later messages in context, knowing which SWF file began the Flash Player session that generated the log.

Requests that depend on policy files

Searching for <allow-access-from> in policy files to authorize 
data loading from resource at (URL) by requestor from (URL).

A SWF file has attempted an operation that requires data-loading permission from a policy file, and a search will now begin for such a policy file. The URLs in this message tell you where the SWF file was loaded from and what resource the SWF file requested.

Searching for <allow-http-request-headers-from> in policy files 
to authorize header sending to URL (URL) by requestor from (URL).

A SWF file has attempted an HTTP operation with custom request headers, which requires header-sending permission from a policy file, and a search will now begin for such a policy file. The URLs in this message tell you where the SWF file was loaded from and where the SWF file is attempting to send custom HTTP request headers.  See the article Understanding Flash Player 9 April 2008 Security Update compatibility for details regarding header-sending permissions.

Request for resource at (URL) by requestor from (URL) is permitted 
due to policy file at (URL).

A SWF file has attempted an operation that requires permission from a policy file, and a policy file was found that permitted the operation. The URLs in this message tell you what resource the SWF file requested, where the SWF file was loaded from, and which policy file granted the permission. Note that it is possible that multiple policy files would have permitted the operation, but only one of them is mentioned in this type of log message.

Request for resource at (URL) by requestor from (URL) has failed 
because the server cannot be reached.

A SWF file has attempted to make a socket connection, but the socket server is unreachable at the moment. The URLs in the message tell you what server and port the SWF file attempted to connect to, and where the SWF file was loaded from. For security reasons, In ActionScript, the SWF file will receive exactly the same error indication as if the server were reachable, but no permission had been granted for the operation; in ActionScript 3.0, this indication is a securityError event.

Request for resource at (URL) by requestor from (URL) is denied 
due to lack of policy file permissions.

A SWF file has attempted an operation that requires permission from a policy file, but no valid policy file was found that permitted the operation. The URLs in the message tell you what resource the SWF file requested, and where the SWF file was loaded from.

This message may occur for many reasons; it indicates a required step that failed to occur, rather than a particular problem that did occur. In some situations, there will be other, more specific messages that come before this message, and they may give you more information before this final failure message. Among the possible causes:

• No applicable policy file exists to authorize the operation. If you control the server where the resource resides, you may need to add a policy file on that server. Otherwise, you may need to proxy the operation through the SWF file's own server.
• An applicable policy file exists, but the server where both the policy file and the resource are located is unreachable at the moment. Try pinging the server host to see if it appears to be reachable. If the SWF file called allowDomain to load an applicable policy file, this message will generally be preceded by the message "Failed to load policy file from (URL)". Note that, for a socket connection, you should see the previously listed message instead for this situation ("...because the server cannot be reached"), but for any other request, you should see this message.
• An applicable policy file exists, but it does not grant permission for access by the SWF file's particular domain. Try getting the SWF file's domain listed in an existing policy file, moving the SWF to a domain authorized by an existing policy file, adding a new policy file, or proxying the request through the SWF file's own server.
• An applicable policy file exists, but it is in a non-default location, and the SWF file attempting the operation did not call allowDomain to inform Flash Player of the policy file's location. Try calling allowDomain from the SWF file.
• An applicable policy file exists, but it is invalid for some reason. In this case, this message should be preceded by a more specific message that shows the policy file URL and the problem that was found; see the section on messages about failures to load policy files.

Phase 1 deprecated configurations

Domain (domain) does not specify a meta-policy. Applying default 
meta-policy 'all'. This configuration is deprecated.

This is a very common message that you will see any time Flash Player obtains a policy file from an HTTP, HTTPS, or FTP server that has not yet specified a meta-policy. In Phase 1, this is only a warning reminding you that this server needs to choose a meta-policy by the time a Phase 2 Flash Player (Flash Player 10.0) is released, or else Flash content might stop working as intended. See the section on meta-policies.

Phase 1.5 forbidden configurations

SWF from (URL) may not connect to a socket in its own domain 
without a policy file.

A SWF file initiated a socket connection to its own domain, and no policy file was found to authorize the operation. Strict policy file rules require permission from a socket policy file to make any socket connection, even to a SWF file's own domain. See the section on socket policy files. The recommended action is to add a socket master policy file server on port 843.

Platform warnings

HTTP response headers not available on this platform.  
Strict policy file rules cannot be enforced.

Flash Player made an HTTP request, and was not able to see HTTP response headers. As detailed in the section on meta-policies, some of the new strict policy file rules require that Flash Player be able to access HTTP response headers, for example so that Content-Type and X-Permitted-Cross-Domain-Policies information from the server is known. Any meta-policy information from servers will be unavailable. For a list of precise effects, and a list of browser configurations where this behavior is expected, see the browser dependency appendix. This warning should not indicate that previously working content will stop working; rather it indicates that the new, stricter rules cannot be enforced, which may result in reduced security for servers and users. The latest versions of most popular browsers enable Flash Player to see HTTP response headers, so upgrading your browser will usually eliminate this message.

Successful policy file loading

Policy file accepted: (URL).

A policy file from the indicated URL has successfully been loaded, has passed all validity checks, and has been accepted by Flash Player. Any <allow-access-from> directives in the policy file will now take effect. This policy file might have been loaded because a SWF file explicitly requested it by calling loadPolicyFile, or it may have been located automatically by Flash Player's default policy file rules.

Warnings while loading policy files

Policy file requested from (URL) redirected to (URL); 
will use final URL in determining scope.

Flash Player requested an HTTP policy file, and the original request was redirected to a different location in the same domain. As detailed in the section on redirects, beginning with version 9,0,115,0, Flash Player has changed its interpretation of HTTP policy files that are obtained from URLs that are redirected within the same domain. Prior to version 9,0,115,0, Flash Player would treat redirected policy files as though they had originated from the URL that was initially requested. Since version 9,0,115,0, however, Flash Player has treated redirected policy files as though they had originated from the final, post-redirect URL. This difference may affect the scope of such a policy file—the set of resources to which it allows access. If you see this warning, check further down the log to see if all requests that depend on this policy file are in fact still succeeding. If they are not, you may need to add a non-redirected policy file at the originally requested URL. You can also put a non-redirected policy file at a different URL, which may require adding or changing loadPolicyFile calls in SWFs to use the new policy file URL. In any case, you should consider avoiding redirecting policy file requests, since they tend to make policy file debugging more difficult.

Domain (domain) does not explicitly specify a meta-policy, 
but Content-Type of policy file (URL) is 'text/x-cross-domain-policy'.
Applying meta-policy 'by-content-type'.

Flash Player has retrieved an HTTP policy file from the indicated URL, and has looked for a meta-policy in HTTP headers and in the master policy file for this domain, but found no meta-policy. However, the policy file was returned with a Content-Type of text/x-cross-domain-policy, which is an indication that the administrator of this server has deliberately made changes to support meta-policies. Since the official Content-Type for HTTP policy files is in use in this domain, Flash Player is assuming a meta-policy of by-content-type for this domain. See the section on specifying meta-policies. It is recommended that, for clarity, this server should explicitly declare a meta-policy, rather than relying on this implicit mechanism. This can be done using a <site-control> tag in the master policy file, or using the HTTP response header X-Permitted-Cross-Domain-Policies.

Timeout on (URL) (at 3 seconds) while waiting for socket policy file.

Flash Player requested a socket policy file by default (either from port 843 or from the same port as a connection attempt), and the socket policy file request resulted neither in success nor in a detectable failure; the server that Flash Player was attempting to contact did not respond within 3 seconds. This might be due to a server not expecting to receive policy file requests, or due to network problems between client and server. When Flash Player requests socket policy files by default, it waits only 3 seconds for a response, in order to avoid tying up server resources or delaying client-side notifications of problems; see the section on socket policy files. This warning usually means one of two things: first, that you need to set up a socket policy file server on port 843, which is the first location that Flash Player checks by default; or second, that you need to provide more explicit guidance to Flash Player from ActionScript by calling loadPolicyFile to indicate the location of a socket policy file. When you call loadPolicyFile rather than allowing Flash Player to check locations by default, Flash Player will wait as long as necessary for a response from a socket policy file server, rather than timing out after 3 seconds. This may help your application's reliability in marginal network conditions. It can thus be helpful to call loadPolicyFile even for a default socket policy file location—simply to request that Flash Player wait patiently for the socket policy file server to respond.

Failures to load policy files

Failed to load policy file from (URL).

Flash Player attempted to retrieve a policy file from the indicated URL, and encountered an error. This might be because of network problems, because a server is not running at this location, or because a server is running but did not recognize the location requested (e.g., HTTP 404 error). This message appears as an error for locations that were passed to loadPolicyFile, as a warning for HTTP/HTTPS/FTP locations that Flash Player has requested by default, and not at all for socket policy file locations that Flash Player has requested by default.

Ignoring policy file at (URL) due to incorrect syntax.

Flash Player retrieved a policy file from the indicated URL, but found that the policy file contained invalid syntax. The policy file has been ignored and will not authorize any operations. See the section on malformed policy files for an explanation of why proper syntax is enforced, and what common kinds of incorrect syntax can result in this error. You (or whoever maintains this policy file) should fix the incorrect syntax as soon as possible. This rule has been enforced since even before Phase 1—starting with Flash Player version 9,0,47,0.

Ignoring policy file at (URL) due to bad Content-Type '(content-type)'.

Flash Player retrieved an HTTP policy file from the indicated URL, but found that the HTTP Content-Type of the policy file was not consistent with normal policy files. To help protect this server, this policy file has been ignored and will not authorize any operations. See the section on the Content-Type whitelist for details. You (or whoever maintains this policy file) should change the unsuitable Content-Type as soon as possible.

Ignoring policy file at (URL) due to missing Content-Type.

Similar to the above error, but Flash Player found no Content-Type at all.

Ignoring policy file requested from (URL) because a cross-domain 
redirect to (URL) occurred.

Flash Player attempted to retrieve a policy file from the first URL indicated, but was redirected to the second URL indicated, which is in a different domain. This is forbidden, and always has been. This policy file has been ignored and will not authorize any operations.

Ignoring policy file at (URL) due to meta-policy '(meta-policy)'.

Flash Player retrieved a policy file from the indicated URL, but also found the indicated meta-policy on that policy file's server, either in a <site-control> tag in the master policy file, or in an X-Permitted-Cross-Domain-Policies HTTP header. The indicated meta-policy expressly forbids this file from being valid as a policy file, so this policy file has been ignored and will not authorize any operations. This message by itself does not necessarily indicate a problem, but if you intended for this policy file to be valid, you may need to change its Content-Type or its FTP filename, or you may need to change the meta-policy.

Ignoring policy file at (URL) due to X-Permitted-Cross-Domain-Policies:
none-this-response.

Flash Player retrieved an HTTP policy file from the indicated URL, but also found the HTTP response header X-Permitted-Cross-Domain-Policies: none-this-response, which is an indication from the server that this HTTP response is not permitted to be used as a policy file. This is usually used to prevent server scripts from generating policy files; see the section on socket meta-policies. This policy file has been ignored and will not authorize any operations. If you control this server, and you need this policy file to authorize operations, you may need to change your server configuration to avoid generating a none-this-response header.

Ignoring socket policy file at (URL) because it is too large.
Socket policy files may not exceed 20 kilobytes.

Flash Player began the process of retrieving a socket policy file from the indicated location, but aborted the download because too much data was received. This policy file has been ignored and will not authorize any operations. This is to help protect the server; Flash Player does not expect policy files to be large, and aborts large policy file downloads to avoid loading the server in what seems to be an error situation. If this is a valid socket policy file, try reducing its size so that it is smaller than 20K.

Meta-policy misconfigurations

Unrecognized meta-policy in HTTP header from (URL): (meta-policy).

An invalid meta-policy was specified in an X-Permitted-Cross-Domain-Policies HTTP header from the indicated URL. It has been ignored. This is a misconfiguration that should be corrected on the server. See the section on meta-policies.

Unrecognized meta-policy in policy file from (URL): (meta-policy).

An invalid meta-policy was specified in a <site-control> tag in a master policy file at the indicated URL. The meta-policy has been ignored, but the policy file itself has not necessarily been ignored (there should be a further error message if it is). You (or whoever controls the content of this policy file) should correct the <site-control> tag so that it contains a valid meta-policy name. See the section on meta-policies.

Conflicting meta-policy in HTTP header from (URL): (meta-policy).

Multiple conflicting meta-policies were found in one or more X-Permitted-Cross-Domain-Policies HTTP header from the indicated URL. The entire meta-policy string is shown, as received from the server. If multiple X-Permitted-Cross-Domain-Policies headers were provided, they have been coalesced here into a single header with semicolon-separated values, as is normal for HTTP headers. Flash Player has applied the most restrictive meta-policy that was found in this string. This is a misconfiguration that should be corrected on the server. It is generally not legal to provide multiple meta-policies in HTTP response headers; the only exception is none-this-response, which may be combined with any other meta-policy, but only affects the individual HTTP response where it is found. See the section on meta-policies.

Meta-policy (meta-policy) in HTTP header from (URL) conflicts 
with previously established meta-policy (meta-policy).

Flash Player found an inconsistent declaration of meta-policy from the server of the indicated URL. Flash Player has applied the most restrictive meta-policy that was found from this server, but if a less restrictive meta-policy was found first, the less restrictive meta-policy may have been in effect for some time until the conflict was found later. This is a misconfiguration that should be corrected on the server. See the section on meta-policies.

Meta-policy (meta-policy) in policy file from (URL) conflicts with 
previously established meta-policy (meta-policy).

Similar to the above error, but the conflicting meta-policy file was discovered in a <site-control> tag rather than an HTTP header.

Ignoring <site-control> tag in policy file from (URL).  
This tag is only allowed in master policy files.

Flash Player found a <site-control> tag in a policy file, from the indicated URL, that was not a master policy file. The <site-control> tag has been ignored, but the policy file itself has not necessarily been ignored (there should be a further error message if it is). The <site-control> tag is only legal in master policy files (/crossdomain.xml on an HTTP/HTTPS/FTP server, or a socket policy file from port 843). You (or whoever controls this server) should remove the <site-control> tag from this policy file, and make sure that this server declares a valid meta-policy by some other means (a master policy file or an HTTP response header). See the section on meta-policies.

Ignoring <site-control> tag in policy file from (URL).  
The 'by-content-type' meta-policy is only applicable to HTTP sites.

Flash Player found a <site-control> tag in a master policy file from the indicated URL, specifying the meta-policy by-content-type in a policy file that was not from an HTTP or HTTPS server. The <site-control> tag has been ignored, but the policy file itself has not necessarily been ignored (there should be a further error message if it is). The by-content-type meta-policy is only valid for HTTP and HTTPS servers, since it relies on Content-Type headers, which are not available from FTP servers or socket servers. You (or whoever controls this server) should choose a valid meta-policy for this server. See the section on meta-policies.

HTTP header from (URL) specifies meta-policy 'by-ftp-filename', 
which is only applicable to FTP, not HTTP.

Flash Player found an X-Permitted-Cross-Domain-Policies HTTP response header while retrieving a policy file from the indicated URL, specifying the meta-policy by-ftp-filename. The X-Permitted-Cross-Domain-Policies header has been ignored, but any policy file at this URL has not necessarily been ignored (there should be a further error message if it is). The by-ftp-filename meta-policy is only valid for FTP servers. You (or whoever controls this server) should choose a valid meta-policy for this server. See the section on meta-policies.

Ignoring <site-control> tag in policy file from (URL).  
The 'by-ftp-filename' meta-policy is only applicable to FTP sites.

Similar to the above error, but the invalid meta-policy was discovered in a <site-control> tag rather than an HTTP header.

Ignoring <site-control> tag in policy file from (URL).
The 'none-this-response' meta-policy is only allowed in the 
X-Permitted-Cross-Domain-Policies HTTP response header.

Flash Player found a <site-control> tag in a master policy file from the indicated URL, specifying the meta-policy none-this-response in a policy file. The <site-control> tag has been ignored, but the policy file itself has not necessarily been ignored (there should be a further error message if it is). The none-this-response meta-policy is only valid in the X-Permitted-Cross-Domain-Policies HTTP response header; it is only intended as a mechanism by which HTTP servers can prevent server scripts from generating policy files. You (or whoever controls this server) should choose a valid meta-policy for this server. See the section on meta-policies.

Policy file at (URL) invalidates its own <allow-access-from> 
directives by declaring the meta-policy 'none'.

Flash Player found a <site-control> tag in a master policy file from the indicated URL, specifying the meta-policy none, but also found <allow-access-from> directives in the same policy file. The declared meta-policy none should be enforced for this server; it means that no policy files are permitted on this server, including the master policy file itself. The master policy file is permitted to exist only to declare the meta-policy. Since the master policy file contains <allow-access-from> directives, they will be ignored. You (or whoever controls this server) should remove the <allow-access-from> directives from this policy file. See the section on meta-policies.

Policy file misconfigurations

Ignoring 'secure' attribute in policy file from (URL). The 'secure' 
attribute is only permitted in HTTPS and socket policy files.

Flash Player found a policy file, from the indicated URL, that contained one or more <allow-access-from> directives that specified the attribute secure="true" or secure="false", but this is neither an HTTPS policy file nor a socket policy file. The secure attribute has been ignored, but the <allow-access-from> directive is not necessarily being ignored (there will be a further error message if it is). The secure attribute, which instructs Flash Player whether to require strong authentication (i.e., HTTPS URLs only) of the domain named in an <allow-access-from> directive, is only legal in HTTPS policy files and socket policy files. This rule has been enforced since policy files were first introduced. This is because the policy file itself is not being transmitted over a tamper-resistant protocol, so a man-in-the-middle attacker could replace a secure="true" declaration with secure="false", which would then allow a non-HTTPS SWF file to retrieve data from this domain, contrary to the policy expressed in this policy file. You (or whoever controls this server) should remove the secure attribute from this policy file.

Found secure='true' in policy file from (URL), but host (host) does not
appear to refer to the local machine.  This may be insecure.

Flash Player found a socket policy file, from the indicated URL, that contained one or more <allow-access-from> directives that specified the attribute secure="true" or secure="false", but the socket policy file does not appear to have come from the local machine. The secure attribute should be enforced as specified, but if this socket policy file did in fact come from somewhere other than the local machine, you may have an insecure configuration. The secure attribute, which instructs Flash Player whether to require strong authentication (i.e., HTTPS URLs only) of the domain named in an <allow-access-from> directive, is effective in socket policy files served from the local machine, because there is no network transmission in which a man-in-the-middle attacker could substitute a different policy file. However, if a socket policy file is served from a remote host, specifying secure="true" may provide a false sense of security, because the socket policy file is transmitted in a way that may be vulnerable to man-in-the-middle attacks. Flash Player does not yet provide a way to retrieve a socket policy file over a secure channel. See the section on socket policy files.

Policy file parsing errors

Ignoring invalid <allow-access-from> tag for domain '(domain)' in 
policy file at (URL).

Flash Player found a policy file from the indicated URL, containing the indicated string as a value for the domain attribute in an <allow-access-from> directive. This string was not recognized as a valid domain. This particular <allow-access-from> directive will be ignored, although other directives in the same policy file may be valid and accepted. You (or whoever controls this policy file) should try to fix the invalid domain.

Ignoring illegal port number specification '(port-string)' in 
policy file at (URL).

Flash Player found a policy file from the indicated URL, containing the indicated string as a value for the to-ports attribute in an <allow-access-from> directive. This string was not recognized as a valid port range. Port ranges may include the wildcard *, individual port numbers, port ranges separated by dashes, or comma-separated lists of individual numbers and/or ranges. This particular <allow-access-from> directive will be ignored, although other directives in the same policy file may be valid and accepted. You (or whoever controls this policy file) should try to fix the invalid port range.

Page 7 of 7

Previous Page