Skip to content
This repository has been archived by the owner on Jun 25, 2022. It is now read-only.

Packer v2 http.FileServer(box) failed to serve index.html with go v1.12.4 and packr Version 2.2.0? #198

Closed
0112358132134-my opened this issue May 5, 2019 · 12 comments
Labels
help wanted Extra attention is needed

Comments

@0112358132134-my
Copy link

Hello,

index.html create a redirect loop then fail with url like "http://localhost:3000//"

(All other static file work as expected);

OS MacOs v10.14.4
Go version 1.12.4
Packr2 V2.2.0

test program :

package main

import (
  "fmt"
  "net/http"

  packr "github.com/gobuffalo/packr/v2"
)

func main() {
  box := packr.New("my template", "../mysite/templates")

  http.Handle("/", http.FileServer(box))
  fmt.Println("listening on :3000")
  http.ListenAndServe(":3000", nil)
}
@marcotuna
Copy link

marcotuna commented May 8, 2019

Hello, same thing happened with me.
Using:

go.12
packr2 v2.2.0
Linux Mint 18.2 Sonya

I should note that my code was working fine with packr 1

@StevenWeathers
Copy link

Also observing this problem

Windows 10
go 1.12.4
packr2 v2.2.0

Was using statik and look forward to switching to this solution

@nlepage
Copy link
Contributor

nlepage commented May 13, 2019

Hi @gpkfr @marcotuna @StevenWeathers

I also ran into this issue, I tried to make a fix if you want to have a look : #201

@0112358132134-my
Copy link
Author

Hi @gpkfr @marcotuna @StevenWeathers

I also ran into this issue, I tried to make a fix if you want to have a look : #201

yes, it seem to resolve this issue. Thanks for your time ;)

@ItalyPaleAle
Copy link

I have the same issue, inside a Buffalo app.

When I put my "index.html" file inside the "public" folder, I get redirected to an invalid location. At the same time, requesting other files (or skipping packr and loading from the filesystem directly) works.

curl -v http://localhost:3001/
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 3001 (#0)
> GET / HTTP/1.1
> Host: localhost:3001
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Cache-Control: max-age=31536000
< Etag: 159eb8d6c587bfa0
< Location: ..//
< Vary: Origin
< Date: Wed, 15 May 2019 02:02:33 GMT
< Content-Length: 0
<
* Connection #0 to host localhost left intact

@sagikazarmark
Copy link
Contributor

See #173

@ItalyPaleAle
Copy link

@sagikazarmark I looked at the issue but not sure what to make out of that?

@sagikazarmark
Copy link
Contributor

As far as I can tell it's the same issue. I posted my findings and a possible workaround there, but it turned out later there is already a PR for the issue.

@mattmcnally
Copy link

Has there been any updates to this issue? I am also running into this same issue using Go v1.12.4 and Packr v2.3.2 and run into the same redirect loop with a URL like http://localhost:3000//.

I am using the same script as is directed in the v2 README for serving static web files from a binary:

package main

import (
	"net/http"

	"github.com/gobuffalo/packr/v2"
)

func main() {
	box := packr.New("someBoxName", "./templates")

	http.Handle("/", http.FileServer(box))
	http.ListenAndServe(":3000", nil)
}

I also noticed the PR from @nlepage above, I will test this to see if it fixes my issues - has there been any updates to its status?

markbates added a commit that referenced this issue Jul 8, 2019

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
…#201)" (#217)

This reverts commit 662c20c.
AlbinoDrought added a commit to AlbinoDrought/creamy-videos that referenced this issue Jul 14, 2019
some kind of change was made and versions of creamy-videos built
with newer versions of packr2 caused redirect loops on webroot.
attempted fixing this using a couple methods but didn't have any luck.

there was a fix added here but it was later (temporarily) reverted:

gobuffalo/packr#198
gobuffalo/packr#217
@Thebarda
Copy link

Hello there,
@markbates : Is there any reason why did you revert #217 ? Because #201 fix the issue

@markbates
Copy link
Member

Yes. As I said the tests keep failing. Another PR needs to be opened to resolve the failing tests.

@mhewedy
Copy link

mhewedy commented Oct 4, 2019

I have this little workaround: https://gist.github.com/mhewedy/65895bced03e75167f2c78cc08994cb8

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

10 participants