Feature Request P2
Status Update
Comments
al...@gmail.com <al...@gmail.com> #2
Hello,
Thank you for reaching out to us!
This issue seems to be outside of the scope of Issue Tracker. This Issue Tracker is a forum for end users to report bugs
and request features
on Google Cloud products. Please go through
I recommend you to
For now, I'm going to close this thread which will no longer be monitored. In case you want to report a new issue, please do not hesitate to create a new Issue Tracker describing your issue.
Thank you!
pr...@google.com <pr...@google.com> #3
Can you list the issue that was closed as wontfix?
[Deleted User] <[Deleted User]> #6
It would be great if this feature was implemented on a per-handler basis similar to:
handlers:
- url: /img/
static_dir: img
missing: img/file-not-found.jpg
handlers:
- url: /downloads/
static_dir: downloads
missing: downloads/no-such-file.htm
handlers:
- url: /img/
static_dir: img
missing: img/file-not-found.jpg
handlers:
- url: /downloads/
static_dir: downloads
missing: downloads/no-such-file.htm
ke...@aladdinschools.com <ke...@aladdinschools.com> #7
All we need is a new error_code in error_handlers:
error_handlers:
- file: default_error.html
- error_code: over_quota
file: over_quota.html
- error_code: not_found
file: not_found.html
In fact just routing static 404 errors default_error.html as above would be a huge win.
It appears the dev server(s) don't actually use the error_handlers. I'd be ok if this fix was production only.
I know this isn't going happen, so I'll just have to change the static handler to being a dynamic handler if I want to catch 404 errors. Sigh.
error_handlers:
- file: default_error.html
- error_code: over_quota
file: over_quota.html
- error_code: not_found
file: not_found.html
In fact just routing static 404 errors default_error.html as above would be a huge win.
It appears the dev server(s) don't actually use the error_handlers. I'd be ok if this fix was production only.
I know this isn't going happen, so I'll just have to change the static handler to being a dynamic handler if I want to catch 404 errors. Sigh.
pa...@google.com <pa...@google.com> #8
Hi All,
The global "error_handlers" section is meant to respond to errors on the platform such as a quota-limit or a serious app failure. With this in mind, however, a feature request has been created for a "not_found" attribute on static handler entries that would be returned in the event of a failure. If the returned value is a web page, it can contain a redirect or custom JS to handle the error more dynamically. The point of static handlers is to enable high-performance serving of static content; If more specific custom routing is desired, a proper dynamic handler is the way to go.
This issue will be considered closed for now, and will be updated in the future when the feature request has been implemented.
Regards,
paynen
The global "error_handlers" section is meant to respond to errors on the platform such as a quota-limit or a serious app failure. With this in mind, however, a feature request has been created for a "not_found" attribute on static handler entries that would be returned in the event of a failure. If the returned value is a web page, it can contain a redirect or custom JS to handle the error more dynamically. The point of static handlers is to enable high-performance serving of static content; If more specific custom routing is desired, a proper dynamic handler is the way to go.
This issue will be considered closed for now, and will be updated in the future when the feature request has been implemented.
Regards,
paynen
du...@gmail.com <du...@gmail.com> #9
In case helpful to others in the meantime, this solution is working for me: https://www.npmjs.com/package/gae-static-yaml
ca...@rodarmor.com <ca...@rodarmor.com> #10
What's the status of this feature?
All workarounds for this are pretty hacky.
All workarounds for this are pretty hacky.
[Deleted User] <[Deleted User]> #11
I'm really surprised there isn't a decent solution here. Using GAE for a static site (https://cloud.google.com/appengine/docs/standard/python/getting-started/hosting-a-static-website ) for a real business/brand is practically impossible if you can't give the user a good experience when they inevitably land on a 404 page. We're trying to move our blog from Medium to our GAE site, but this limitation has us rethinking that decision.
is...@google.com <is...@google.com>
ri...@chemicalloche.com <ri...@chemicalloche.com> #12
I just hit this, and it's really amazing and surprising to me as well that this hasn't been implemented after all these years. 😱
There's no decent workaround either. I resorted to the 'gae-static-yaml' workaround (https://www.npmjs.com/package/gae-static-yaml ), very reluctantly I might add, but even that results in hitting the upper limit for the URLMap entries in app.yaml while deploying.
I'd love to host my static sites along with my apps on App Engine, but this is forcing me to go somewhere else. Most static hosting platforms default to using a custom 404.html at the root, for any 404 errors.
This is a fairly highly requested feature (both on Stack Overflow and this issue tracker), and it surely needs some love from the App Engine engineers. I highly suggest prioritizing this feature request. 🙏
There's no decent workaround either. I resorted to the 'gae-static-yaml' workaround (
I'd love to host my static sites along with my apps on App Engine, but this is forcing me to go somewhere else. Most static hosting platforms default to using a custom 404.html at the root, for any 404 errors.
This is a fairly highly requested feature (both on Stack Overflow and this issue tracker), and it surely needs some love from the App Engine engineers. I highly suggest prioritizing this feature request. 🙏
Description
error_handlers:
- file: error.html
handlers:
- url: /static
static_dir: static
- url: /.*
script:
secure: always
then access to /static/doesnotexist generates a 404 error. The request is *not* routed to the /.* handler, and is not caught by the error_handlers stanza.
This 404 should be catchable in some way. Preferably via the error_handlers stanza.
There is a related bug to this which is labelled 'wontfix', but I think that the closer did not understand that this case exists. Alternatively, if there is a workaround for this case, then please include it in the 'wontfix' description.