-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
favicon.ico #28
Comments
Yeah I've been getting that too, but I think it's largely inconsequential as it only happens when you open the service itself in a browser. Generally, when used something like this: fetch('myservice.com/bla') No |
Yeah, though I think it's worth saying that it will probably apply to any developer looking to see how the service works. Because that's just so easy of a test to play around. I wonder if there is a way to support user-supplied filtering logic of requests going into the service. I think this is one use case but there might be plenty of others like IP whitelisting, blocking of endpoints that are being abused by a malicious 3rd party, any request that contains a "password" field, etc. |
Yeah this'll probably tie into #11. Maybe we need some sort of general extensibility? |
I think so |
We can maybe add this to the nginx example?
|
Not a bad idea either! |
I like that, simple solution! 👏 |
I've been using chrome to open up views to test and it's requesting for favicon.ico. Is there something we could/should do here? I think this could be a common usage pattern for people trying out the project/testing it.
So some sort of filtering or blacklist?
The text was updated successfully, but these errors were encountered: