Google Cloud backend bucket not returning the image object

[mountaincode2]

I am following the tutorial:

https://cloud.google.com/load-balancing/docs/https/setup-global-ext-https-buckets#buckets_as_load_ba...

I have followed all the steps and set up my backend buckets that point to storage buckets.

However when i point to my load balancer's forwarding rule IP in the browser, i get the following error:

This XML file does not appear to have any style information associated with it. The document tree is shown below.
<ListBucketResult>
<Name>kierkegaard-bucket</Name>
<Prefix/>
<Marker/>
<IsTruncated>false</IsTruncated>
<Contents>
<Key>cat.jpeg</Key>
<Generation>1723653909535859</Generation>
<MetaGeneration>1</MetaGeneration>
<LastModified>2024-08-14T16:45:09.539Z</LastModified>
<ETag>"603be4bf40ae47559b446501d13ffe1f"</ETag>
<Size>242448</Size>
</Contents>
</ListBucketResult>

What am i missing here please?

[poncejohn · Accepted solution]

Hi @mountaincode2,

The idea behind unmatched paths is that they allow any existing path within your buckets to be read. Any path that doesn't match a specific rule will be served by your default backend bucket. Let's examine your provided routing rules and backend buckets.

Routing rules:

All unmatched (default)	All unmatched (default)	kierkegaard-backend
*	/seneca/*	seneca-backend
*	All unmatched (default)	kierkegaard-backend

Based on your configuration, your default backend bucket is kierkegaard-backend, which handles all paths that exist within it. However, any request targeting /seneca/*, such as "http://<loadbalancer_front_end_IP>/seneca/dog.jpg" (assuming dog.jpg exists), will use seneca-backend. For instance, if the /seneca/ folder also exists within your default backend (kierkegaard-backend), your load balancer will prioritize seneca-backend because you have a specific path rule for /seneca/*.

Furthermore, if objects are not being served, it's likely due to requesting non-existent paths or objects as previously discussed.

I hope this gives you an idea.

[mountaincode2]

Can anyone please help. Thank you!

[yrhsk]

Seems that your load balancer is correctly pointing to the storage bucket, but it's displaying the bucket's XML listing instead of serving the content as a website. This usually happens when the bucket isn't configured to serve static content. Make sure you've set up the bucket to host a static website by enabling the "Website configuration" in your Google Cloud Storage settings. You should specify an index page (like index.html) so that the load balancer knows what to serve when accessed.

[poncejohn]

Hi @mountaincode2 ,

Welcome to Google Cloud Community!

To verify whether your load balancer will serve the image that has been uploaded on your bucket, a “cat.jpeg” must be included within your request. 

See example below:

http://<loadbalancer_front_end_IP>/cat.jpeg

Basically, you are just calling the loadbalancer’s front end IP without any index page yet.

With regards to setting up the index page, you may follow @yrhsk 's recommendations.

I hope the above information is helpful.

[mountaincode2]

Hi @poncejohn 

But i have my routing rules in the URL map set up as follows.

So requests should go to the `kierkegaard-backend` with just the IP address as well.

Also, what configuration changes do i have to make in the console/gcloud in order for Cloud Storage buckets to serve static content.

Routing rules

HostsPathsBackend

All unmatched (default)	All unmatched (default)	kierkegaard-backend
*	/seneca/*	seneca-backend
*	All unmatched (default)	kierkegaard-backend

[mountaincode2]

Any thoughts please on how i can get this working?

[mountaincode2]

ah okay, i see this section:

https://cloud.google.com/storage/docs/hosting-static-website#specialty-pages

You can assign an index page suffix and a custom error page, which are known as specialty pages. Assigning either is optional, but if you don't assign an index page suffix and upload the corresponding index page, users who access your top-level site are served an XML document tree containing a list of the public objects in your bucket.

[poncejohn]

Hi @mountaincode2,

Yes, that is correct. If you haven't configured your index page yet, the load balancer will serve an XML document tree listing the public objects in your designated bucket.

You can use the gcloud storage buckets update command in the CLI to set your object as the main page instead of displaying the usual bucket listing. Based on the bucket and object name you provided, you can try this command:

gcloud storage buckets update gs://kierkegaard-bucket --web-main-page-suffix=cat.jpeg

So once you access your load balancer's frontend IP in your browser, it should display your cat.jpeg object as the main page.

I hope this helps!

[mountaincode2]

Hi @poncejohn , thanks for sharing the flag `web-main-page-suffix`:

https://cloud.google.com/sdk/gcloud/reference/storage/buckets/update#--web-main-page-suffix

[mountaincode2]

Also @poncejohn a quick followup:

The following are my routing rules:

All unmatched (default)	All unmatched (default)	kierkegaard-backend
*	/seneca/*	seneca-backend
*	All unmatched (default)	kierkegaard-backend

When i go to

http://<loadbalancer_front_end_IP>/cat.jpeg

I can see the cat.jpeg image.

But when i enter another unmatched path, say http://<frontend-ip>/abc, i do not see the cat.jpeg image.

Why is that so. Shouldn't unmatched paths also point to `kierkegaard-backend`, which then points to the `kierkegaard-bucket` that contains cat.jpeg.

Please let me know what is it that i am missing here.

[poncejohn]

Hi @mountaincode2,

When you request a non-existent object, you encounter an error because the requested resource is not found. To handle this, you should configure an error page. This error page will be served by your load balancer whenever a user attempts to access a non-existent object. You can achieve this by utilizing the --web-error-page flag.

For instance, you can use the following command:

gcloud storage buckets update gs://kierkegaard-bucket --web-error-page=cat.jpeg

So whenever a request is made for a non-existent object, the load balancer will serve the cat.jpeg object as your designated error page as well.

I hope this helps!

[mountaincode2]

@poncejohn  but what i mean to say is shouldn't unmatched paths (for example, <frontend_IP>/abc-path) also point to the `kierkegaard-backend` which contains `cat.jpeg`. So shouldn't any unmatched path go to the `kierkegaard-backend` and then return `cat.jpeg`?

[mountaincode2]

Can someone please help me with this query.

Thank you for your time!

[poncejohn · Accepted solution]

Hi @mountaincode2,

The idea behind unmatched paths is that they allow any existing path within your buckets to be read. Any path that doesn't match a specific rule will be served by your default backend bucket. Let's examine your provided routing rules and backend buckets.

Routing rules:

All unmatched (default)	All unmatched (default)	kierkegaard-backend
*	/seneca/*	seneca-backend
*	All unmatched (default)	kierkegaard-backend

Based on your configuration, your default backend bucket is kierkegaard-backend, which handles all paths that exist within it. However, any request targeting /seneca/*, such as "http://<loadbalancer_front_end_IP>/seneca/dog.jpg" (assuming dog.jpg exists), will use seneca-backend. For instance, if the /seneca/ folder also exists within your default backend (kierkegaard-backend), your load balancer will prioritize seneca-backend because you have a specific path rule for /seneca/*.

Furthermore, if objects are not being served, it's likely due to requesting non-existent paths or objects as previously discussed.

I hope this gives you an idea.

[mountaincode2]

@poncejohnthank you so much for the clarification.

ah okay... so even the unmatched path still need to be existing paths within the buckets. i was under the impression that it could be any random path (unrelated to the paths within the buckets). Did i get this right.

[poncejohn · Accepted solution]

Hi @mountaincode2,

That is correct. Your request should specify an existing path and object within your default bucket. This is why you are receiving a raw XML response due to the path not existing and no object within your request.

If you want your load balancer to serve a web error page whenever a request is not found, you can use the    “--web-error-page” flag, as previously discussed.

I hope this helps!