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

hugo server should check for /foo.html when requesting /foo #2242

Closed
octref opened this issue Jun 29, 2016 · 7 comments
Closed

hugo server should check for /foo.html when requesting /foo #2242

octref opened this issue Jun 29, 2016 · 7 comments

Comments

@octref
Copy link
Contributor

octref commented Jun 29, 2016

I'm using https://surge.sh/ to deploy my hugo site. It has a great clean url feature, so if you have /foo.html, /foo will get it, /foo/ will redirect to /foo.

So now I'm creating content/foo.md, and enabling uglyurls so hugo generates /foo.html.

In some pages, such as listing page, I'm now using {{ trim .RelPermalink ".html" }} to use clean url in href. However, this causes problem with hugo server. A request of /foo doesn't check the existence of /foo.html, but directs to /foo/ to try /foo/index.html immediately.

@anthonyfok anthonyfok added the Wish label Jul 1, 2016
@octref
Copy link
Contributor Author

octref commented Oct 2, 2016

@anthonyfok Hey I'm interested in doing this myself, but I don't have much experience with golang. or hugo. Would you mind giving me a pointer as to where to start?

@bep
Copy link
Member

bep commented Oct 2, 2016

@octref this issue is in the category of "we should most likely not do this", and if so only if it is really simple and someone is providing a finished solution for it. Teaching you Golang doesn't fit that bill.

@octref
Copy link
Contributor Author

octref commented Oct 2, 2016

@bep I understand that. Just want to know where to start. Guess I'll look into https://github.com/spf13/hugo/blob/master/commands/server.go and how net/http fileserver handles request.

Just wondering, is it that you are against this feature?
If not, are you OK if I do it this way?

/foo serves /foo.html if it's available. If not, directs to /foo/ and behave like it is before.

@octref
Copy link
Contributor Author

octref commented Oct 2, 2016

Knowing "we should most likely not do this" is useful as I can possibly avoid the awkward situation where I take time to do a PR and you don't want this feature at all.

Also saw your comment at #874:

@rustyoz I agree, but I still feels that the FileServer devs should have made this extensible in the first place. When they sober up from GopherCon I will post an issue; but that will be Go 1.6 at best.

I guess this discussion can hold until we decide what to do about a REST api.

So as for approach to this problem:

  • Is FileServer made extensible now go is 1.7?
  • Does hugo need to take dep on https://github.com/julienschmidt/httprouter to implement this feature?
  • Or is it you are doing the REST api(didn't see it in code, and didn't find it on roadmap)?

@octref
Copy link
Contributor Author

octref commented Oct 24, 2016

Guess I'll should switch back to jekyll.

@octref octref closed this as completed Oct 24, 2016
@carlmjohnson
Copy link
Contributor

I'm not sure I understand this feature request.

Is it that you want the page URL to be /a/ but you want the filename to be /a.html instead of /a/index.html so your provider will do redirects? If so, there's no need to adjust Hugo. Just write a script (could be in any language, doesn't have to be Go) to move /a/index.html to /a.html after you've done a build with Hugo, since it's really about the final file locations, not the URL as Hugo understands them.

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 21, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants