starred/fake-gcs-server

Fork 0

mirror of https://github.com/fsouza/fake-gcs-server.git synced 2026-04-25 21:55:56 +03:00

[GH-ISSUE #637] Raise an error for invalid externalURL #114

New issue

Open

opened 2026-03-03 12:08:24 +03:00 by kerem · 5 comments

kerem commented

2026-03-03 12:08:24 +03:00

Owner

Originally created by @adriangb on GitHub (Dec 20, 2021).
Original GitHub issue: https://github.com/fsouza/fake-gcs-server/issues/637

Hi, I'm coming here from https://github.com/googleapis/python-storage/issues/604

The TLDR is that inside of docker-compose at least, the externalURL value inferred from server's bind is not valid.

Would it be possible to detect this and error out if no -external-url parameter was provided by the user? It would avoid a pretty difficult to debug-bug.

I also noticed that in the logs I always see server started at http://[::]:4443 even when running out of docker compose, so it seems that maybe the inference of the bound hostname is overall wrong? I don't know enough about golang or low level networking to be able to tell.

Originally created by @adriangb on GitHub (Dec 20, 2021). Original GitHub issue: https://github.com/fsouza/fake-gcs-server/issues/637 Hi, I'm coming here from https://github.com/googleapis/python-storage/issues/604 The TLDR is that inside of docker-compose at least, the `externalURL` value inferred from server's bind is not valid. Would it be possible to detect this and error out if no `-external-url` parameter was provided by the user? It would avoid a pretty difficult to debug-bug. I also noticed that in the logs I always see `server started at http://[::]:4443` even when running out of docker compose, so it seems that maybe the inference of the bound hostname is overall wrong? I don't know enough about golang or low level networking to be able to tell.

kerem commented

2026-03-03 12:08:25 +03:00

Author

Owner

@fsouza commented on GitHub (Dec 29, 2021):

Hm not sure if we can easily detect a better external URL. We could make it always required, but that would be a breaking change. We could also do something that only affects the Docker image, since I believe that's the environment where people will usually run in this sort of issue (something like an environment variable that turns -external-url into a required parameter? 🙈 )

A less intrusive change would be to log a warning? Something like No -external-url specified, using <...>. Make sure that is accessible by the clients or something like that.

@fsouza commented on GitHub (Dec 29, 2021): Hm not sure if we can easily detect a better external URL. We could make it always required, but that would be a breaking change. We could also do something that only affects the Docker image, since I believe that's the environment where people will usually run in this sort of issue (something like an environment variable that turns `-external-url` into a required parameter? 🙈 ) A less intrusive change would be to log a warning? Something like `No -external-url specified, using <...>. Make sure that is accessible by the clients` or something like that.

kerem commented

2026-03-03 12:08:25 +03:00

Author

Owner

@adriangb commented on GitHub (Dec 29, 2021):

I think a warning would be a good start.

Regarding making it required, could it be required only when calling an endpoint that needs it and when it can't be inferred? It would still technically be a breaking change, but that scenario would lead to a client error anyways so this would just move the error to a more user friendly place.

@adriangb commented on GitHub (Dec 29, 2021): I think a warning would be a good start. Regarding making it required, could it be required only when calling an endpoint that needs it and when it can't be inferred? It would still technically be a breaking change, but that scenario would lead to a client error anyways so this would just move the error to a more user friendly place.

kerem commented

2026-03-03 12:08:25 +03:00

Author

Owner

@stoffeastrom commented on GitHub (Dec 30, 2021):

🤔 Haven't looked into it in detail but I'm thinking maybe it's better to use the request to set the correct headers?

e.g if you're requesting inside docker network it would look in one way but if you exposed it locally it looks different

from inside docker-compose

curl http://<docker-compose-container-name>:port/xyz

from localhost

curl http://localhost:port/xyz

maybe we could just use

baseURL := r.URL.Scheme + `://` + r.URL.Host + `:` + r.URL.Port()
header.Set("Location", baseURL+"/upload/resumable/"+uploadID)

@stoffeastrom commented on GitHub (Dec 30, 2021): 🤔 Haven't looked into it in detail but I'm thinking maybe it's better to use the `request` to set the correct headers? e.g if you're requesting inside docker network it would look in one way but if you exposed it locally it looks different from inside `docker-compose` ```sh curl http://<docker-compose-container-name>:port/xyz ``` from `localhost` ```sh curl http://localhost:port/xyz ``` maybe we could just use ```golang baseURL := r.URL.Scheme + `://` + r.URL.Host + `:` + r.URL.Port() header.Set("Location", baseURL+"/upload/resumable/"+uploadID) ```

kerem commented

2026-03-03 12:08:25 +03:00

Author

Owner

@adriangb commented on GitHub (Dec 30, 2021):

Sounds reasonable to me. Does the GCS client include the location header in all languages?

@adriangb commented on GitHub (Dec 30, 2021): Sounds reasonable to me. Does the GCS client include the location header in all languages?

kerem commented

2026-03-03 12:08:25 +03:00

Author

Owner

@fsouza commented on GitHub (Dec 30, 2021):

Location is the response header set by the server, but I think that's a good idea, if -external-url isn't set, we use the request host. Would potentially need to support X-Forwarded-Host, but we can start with just the host (proxies can rewrite Location as needed, and I wouldn't expect anyone to be running fake-gcs-server behind a reverse proxy).

@fsouza commented on GitHub (Dec 30, 2021): `Location` is the response header set by the server, but I think that's a good idea, if `-external-url` isn't set, we use the request host. Would potentially need to support `X-Forwarded-Host`, but we can start with just the host (proxies can rewrite `Location` as needed, and I wouldn't expect anyone to be running fake-gcs-server behind a reverse proxy).