Skip to content

Latest commit

 

History

History
95 lines (58 loc) · 5.14 KB

troubleshooting.md

File metadata and controls

95 lines (58 loc) · 5.14 KB
Raw
copyright lastupdated
years
2018
2018-04-27

{:shortdesc: .shortdesc} {:new_window: target="_blank"} {:codeblock: .codeblock} {:pre: .pre} {:screen: .screen} {:tip: .tip} {:download: .download}

Troubleshooting

How do I know my CDN is working?

Run the following curl command by replacing http://your.cdn.domain/uri with the respective file path on your CDN:

curl -I -H "Pragma: akamai-x-cache-on, akamai-x-cache-remote-on, akamai-x-check-cacheable, akamai-x-get-cache-key, akamai-x-get-extracted-values, akamai-x-get-nonces, akamai-x-get-ssl-client-session-id, akamai-x-get-true-cache-key, akamai-x-serial-no" http://your.cdn.domain/uri

If the output of the curl command is similar to the following example format, the CDN is working as expected:

    HTTP/1.1 200 OK

    Server: nginx/1.13.0

   ...

    X-Cache: TCP_HIT from a199-117-103-28.deploy.akamaitechnologies.com (AkamaiGHost/9.0.2.1-20488781) (-)

    X-Cache-Key: /L/1363/535014/1d/your.cdn.domain/uri

    X-True-Cache-Key: /L/your.cdn.domain/uri

    ...

    ...

    X-Akamai-Session-Info: name=WSD_BEST_PRACTICES_TD_TYPE; value=PATTERNS_BASED_PARENT_MAP

    X-Serial: 1363

    Connection: keep-alive

    X-Check-Cacheable: YES

I received a 503 error. Why?

The most common reason we have seen for the 503 error is due to an issue with a certificate in the SSL certificate chain.

This is the error you may see: 503 Service Unavailable.

In conjunction with the 503 error, you may also see a message similar to the following: An error occurred while processing your request. Reference #30.3598c0ba.1521745157.87201fff (the actual reference number may vary). In this case, the reference number in the error string translates to a SSL handshake failure.

To correct the issue, ensure that your Origin server's SSL certificate(s) meets the following criteria:

  • The certificate must be issued by a Certification Authority trusted by Akamai. You can view the list of Akamai trusted certificates at this link
  • It must match the Host header configured on the CDN
  • It must not be self-signed
  • It must not be expired

If you have verified your Origin's certificate chain using the previous criteria and you are still encountering the same error, please see our Getting help and support page. Make note of the Reference error string and include it in any communication with us.

What is the expected behavior when loading the CNAME or hostname on your browser for the supported protocols?

Browser URL CDN with HTTP protocol only CDN with HTTPS protocol only CDN with both HTTP and HTTPS protocols
http://hostname Successful load 301 Moved permanently 301 Moved permanently
https://hostname Access denied Redirects to IBM Cloud Webpage Redirects to IBM Cloud Webpage
http://cname 301 Moved permanently Access denied Successful load
https://cname Redirects to IBM Cloud Webpage Successful load Successful load

Notes:

A 301 Moved permanently message most likely indicates you are attempting to reach a CDN with an HTTPS or HTTP_AND_HTTPS protocol using the hostname. Due to a limitation with the HTTPS wildcard certificate, you must use the CNAME for access to your CDN.

With an HTTP only protocol, you will receive the 301 Moved permanently message if you try to reach your CDN using the CNAME. In this case, you can only gain access to your CDN using the hostname.

The Access denied message is seen when you're trying to accreachess a CDN using an incorrect protocol. Ensure that you're using http for CDNs created with HTTP protocol, or https for CDNs created with HTTPS protocol.

The behavior of a URL redirecting to IBM Cloud CDN webpage is seen most often when the URL is incorrect for the protocol. If your CDN is created with a protocol of HTTPS or HTTPS_AND_HTTPS, you must use the CNAME for access to your CDN. For example: https://examplecname.cdnedge.bluemix.net for HTTPS mappings or http://examplecname.cdnedge.bluemix.net or https://examplecname.cdnedge.bluemix.net for HTTP_AND_HTTPS mappings.

The URL redirects to IBM Cloud CDN webpage in this case because both the protocol and domain are incorrect for the CDN's protocol. For a CDN created with HTTP as the only protocol, it can be reached only by means of the hostname. For example, http://example.com.

My hostname doesn't load on the browser when IBM Cloud Object Storage (COS) is the origin.

When your IBM Cloud CDN is configured to use IBM COS as the object storage, direct access to the website will not work. You must specify the complete request path in the browser's address bar (for example, www.example.com/index.html). This behavior is caused by the index document limitation in IBM COS.

I can't connect through a curl command or browser using the Hostname with HTTPS.

Currently HTTPS is supported only through a Wildcard certificate. As a result of this limitation, the connection must be made using CNAME; trying to connect using the Hostname will result in failure.