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

elm-live assumes any URL ending in .com is a static file #209

Open
glasserc opened this issue Jan 9, 2020 · 1 comment · May be fixed by #222
Open

elm-live assumes any URL ending in .com is a static file #209

glasserc opened this issue Jan 9, 2020 · 1 comment · May be fixed by #222

Comments

@glasserc
Copy link

glasserc commented Jan 9, 2020

In my project, I have a registration flow that takes the user to a URL like http://localhost:8080/awaiting-confirmation/[email protected]. Doing pushUrl from the Elm side works fine. However, refreshing this page in the browser causes an error: Cannot GET /awaiting-confirmation/[email protected].

I believe this is due to the code here that analyzes the URL to determine what file type the request is trying to get, in order to determine whether to try to serve a static file or to serve the root page:

elm-live/lib/src/start.js

Lines 109 to 110 in e9af6ec

const fileType = pipe(path.extname, mime.getType)(pathname)
const requestType = getRequestType({ pathname, fileType }, model)

Because this is guessing based on the "extension", any URL that ends in .com is assumed to be a static file.

At first I thought this was a problem with the URL parsing in the path component of a URL, so I also tried as a query string: http://localhost:8080/[email protected]. Unfortunately this gave me the same result (Cannot GET /awaiting-confirmation). I don't like the behavior on just paths, but I think the same behavior on query parameters is definitely wrong.

I can think of a few ways we could try to fix this:

  • Instead of guessing that the path is static because of its mimetype, we could assume any path that we can stat() successfully is static.
  • We could be more opinionated about insisting that static assets be located under certain well-known directories such as public or static.
@wking-io
Copy link
Owner

This is a very good point and something that I didn't have a lot of cases to test the edges of. Would love your thoughts on solutions for this in the code. :)

@glasserc glasserc linked a pull request Mar 22, 2020 that will close this issue
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

Successfully merging a pull request may close this issue.

2 participants