You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sometimes, a build produces a connector that fails to resolve the / url and turns it into an infinite redirect. IIRC it redirects / to /../ or ../ (which the browser flattens to //) which redirects again to the same place.
At one point, @HendryKaak saw this in (I think) a release build, but when he did a development (non-packr) build with extra output, the problem went away and was no longer reproducible.
Today, I had the same problem in a development build, and the problem stayed around, so I dug in. I've found that:
The redirect is generated by net/http's FileServer (which is used as the 404 handler for httprouting).
The FileServer delegates the '/' (or perhaps '' by then) url to packr's Box::Open. This returns a file (rather than a directory), which I believe prevents net/http from looking for /index.html. This is box.open open "/" return dir gobuffalo/packr#173. It also causes it to prepend ../ and redirect, which it apparently does if a request for a file ends with / (though I can't quite understand why prepending .. would be useful).
There is some code inside packr that does the index.html resolution, but I think it does not (always) work (and also that it is the wrong place to do this).
There is another problem with packr that makes it look outside of the box (at least in development mode). I reported this in Defaultresolver accesses current directory before box directory gobuffalo/packr#192. Looking through the code makes me wonder if packr is really as clean in resolving lookings as it should be, so possibly this is also involved.
I'm not entirely sure why this happens sometimes but not always. My best guess would be that it happens if packr2 build was never run (so there is no packrd subdirectory with a bundled frontend). Once that is run, I suspect subsequent builds will use the bundled version, hiding the problem. This does not explain why @HendryKaak saw this in a production build, generated with packr build, though (but perhaps there are multiple problems with the same symptoms).
Sometimes, a build produces a connector that fails to resolve the / url and turns it into an infinite redirect. IIRC it redirects / to /../ or ../ (which the browser flattens to //) which redirects again to the same place.
At one point, @HendryKaak saw this in (I think) a release build, but when he did a development (non-packr) build with extra output, the problem went away and was no longer reproducible.
Today, I had the same problem in a development build, and the problem stayed around, so I dug in. I've found that:
net/http'sFileServer(which is used as the 404 handler forhttprouting).FileServerdelegates the '/' (or perhaps '' by then) url to packr'sBox::Open. This returns a file (rather than a directory), which I believe preventsnet/httpfrom looking for/index.html. This is box.open open "/" return dir gobuffalo/packr#173. It also causes it to prepend ../ and redirect, which it apparently does if a request for a file ends with / (though I can't quite understand why prepending .. would be useful).index.htmlresolution, but I think it does not (always) work (and also that it is the wrong place to do this).I'm not entirely sure why this happens sometimes but not always. My best guess would be that it happens if
packr2 buildwas never run (so there is nopackrdsubdirectory with a bundled frontend). Once that is run, I suspect subsequent builds will use the bundled version, hiding the problem. This does not explain why @HendryKaak saw this in a production build, generated with packr build, though (but perhaps there are multiple problems with the same symptoms).