Skip to content
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

Ignore URL arguments when a file without the arguments exists. #18

Open
berkes opened this issue May 12, 2021 · 1 comment
Open

Ignore URL arguments when a file without the arguments exists. #18

berkes opened this issue May 12, 2021 · 1 comment

Comments

@berkes
Copy link

berkes commented May 12, 2021

Several 3rd party libs rely on arguments such as foo.css?hash=60abbfc70f76d949a785a65742f2a3628c9fe006 or materialdesignicons-webfont.ttf?v=5.8.55. Most often a trick to allow caching (by a CDN or fileserver), but refresh the cache when a new version is rolled out.

devserver then gives an error: Could not find file: /home/redacted/css/fonts/materialdesignicons-webfont.woff2?v=5.8.55

When I create that file, e.g. by adding as symlink, it gets served:
afbeelding

While this "hack" works, it requires changes to the source-code that I'd rather not make.

Ideally, for me, this would work as follows:

When requesting /foo.html?bar=baz

  • If a file foo.html?bar=baz exists, serve that.
  • If no exact file exists, serve foo.html

This way, a static site that is stored from e.g. crawling/mirroring can be served, preserving url-arguments. But in many development-cases, we can ignore any url-arguments and serve the assets and files without the url-arguments.

Some edge-cases to ignore, or consider:

  • How to deal with /foo.html?name=elmo&species=monster versus /foo.html?species=monster&name=elmo.
  • How to deal with /foo.html?name=elmo&species=monster when a file /foo.html?name=elmo exists.
  • How to treat URL-encoded: /foo.html?name=e%26b must it match the file /foo.html?name=e&b?

If this is considered a good feature, I'll try to make a PR that implements the simple version. And if an edge-case is considered crucial, I'll try to include that too.

@kettle11
Copy link
Owner

Sounds good to me! Thanks for thinking this through!

As for the edge cases they could be ignored for now and revisited if they're actually causing a problem for someone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants