By default, buckets do not have any CORS configuration set. To set or modify
CORS for an existing bucket you make a PUT request that is scoped to the bucket
and you use the
cors query string parameter. You must include an
XML document in the request body that contains one or more CORS configurations
that you want to apply. Notice that you cannot set CORS configuration on a new
bucket that you are creating.
You must have
FULL_CONTROL permission to apply a CORS
configuration to an existing bucket. Also, you must be authenticated to use the
PUT Bucket method.
Query string parameters
||You use this to change the CORS configuration on an existing bucket. You must provide the CORS XML document in the request body.||No|
Request body elements
The following diagram shows the nesting of XML elements in the CORS configuration. See the table below the diagram for additional details.
The following request body elements are applicable only if you use the
cors query string parameter to specify CORS for an existing
||Container for one or more Cors configuration containers. If you specify multiple Cors configurations, be aware that the Cors configurations will be evaluated in the order listed within the CorsConfig container, with the first Cors configuration matching the Origin and Method of the request used to determine any CORS response headers to add to the response.|
||Container for a CORS configuration to be applied to the bucket. You can specify multiple Origins and multiple Methods in each Cors container. There will be a match if the request Origin matches any of the Origins in the Cors container and the request Method matches any of the Methods in the Cors container.|
||Container for the origins permitted for cross origin resource sharing with this Cloud Storage bucket.|
||An Origin permitted for cross origin resource sharing with this Cloud Storage bucket. For example,
||Container for one or more HTTP Method elements, specifying the methods permitted in cross origin resource sharing with this Cloud Storage bucket.|
||An HTTP method supported in this configuration. Valid values are GET, HEAD, PUT, POST, and DELETE.|
||Optional container for one or more ResponseHeader elements.|
||Specifies a response header that the user agent is permitted to share across origins.|
||This value is used to respond to preflight requests, indicating the number of seconds that the client (browser) is allowed to make requests before the client must repeat the preflight request. (Indicates cache expiry time.) Preflight requests are required if the request method contains non-simple headers or if the request method is not POST, GET, or HEAD. The value is returned in the Access-Control-Max-Age header in responses to preflight requests.|
PUT /?cors HTTP/1.1 Host: <bucket>.storage.googleapis.com Date: <date and time of the request> Content-Length: <request body length> Content-Type: <MIME type of the body> Authorization: <authentication string> <xml_document_defining_cors>
The request can return a variety of response headers depending on the request headers you use.
Response body elements
The response does not include an XML document in the response body.
The following sample sets a CORS configuration on a bucket named acme-pets. This CORS configuration sets two origins and the HTTP methods allowed for those origins. In this example, all of the available HTTP methods are allowed.
PUT /?cors HTTP/1.1 Host: acme-pets.storage.googleapis.com Date: Thu, 12 Mar 2012 03:38:42 GMT Content-Length: 1320 Authorization: Bearer ya29.AHES6ZRVmB7fkLtd1XTmq6mo0S1wqZZi3-Lh_s-6Uw7p8vtgSwg <?xml version="1.0" encoding="UTF-8"?> <CorsConfig> <Cors> <Origins> <Origin>http://origin1.example.com</Origin> <Origin>http://origin2.example.com</Origin> </Origins> <Methods> <Method>GET</Method> <Method>HEAD</Method> <Method>PUT</Method> <Method>POST</Method> <Method>DELETE</Method> </Methods> <ResponseHeaders> <ResponseHeader>x-goog-meta-foo1</ResponseHeader> <ResponseHeader>x-goog-meta-foo2</ResponseHeader> </ResponseHeaders> <MaxAgeSec>1800</MaxAgeSec> </Cors> </CorsConfig>
HTTP/1.1 200 OK Date: Thu, 12 Mar 2012 03:38:42 GMT Expires: Mon, 01 Jan 1990 00:00:00 GMT Cache-Control: no-cache, no-store, must-revalidate Content-Length: 0 Content-Type: text/html