Open jwiegley opened 7 years ago
@ndmitchell Hi Neil, any ideas on this one? I'd love to update my Docker image on DockerHub, but this bug is blocking the update. For now, I've just switch to using Hoogle directly again, since that continues to work.
Sorry for the delay in replying - I've been swamped with other stuff and not had much time on the internet.
I'm confused. Can you trigger this behaviour outside Docker? Does the --host '*'
actually make any meaningful difference to how files are served? Can you give a concrete example? As my test case I searched for filter
, then clicked on the Bool
in the type signature and ended up at the right documentation. With Hoogle 5 I don't write any links, I just use the fact they are relative links and start by serving them up under file/
which gets preserved.
I have dockerized a local Hoogle server container, available here:
With Hoogle 4, this works perfectly fine. But with Hoogle 5, the port forwarding no longer works correctly. The thing is, I access the website using
http://127.0.0.1:8687
from my machine, but it's not actually a localhost access from the point of view of Hoogle. So with Hoogle 5 I need to add--host
, however, this changes the behavior somewhat:hoogle server --local
is inaccessible now, because I'm connecting through a port forward. This worked in Hoogle 4.hoogle server --host '*'
causes all links to appear asfile://
links, making them unusable, because I don't have direct file access to the server.hoogle server --local --host '*'
rewrites search result links ashttp://127.0.0.1/file/...
, but rewrites links within documentation pages ashttp://127.0.0.1/...
, without thefile/
leader. This makes search links clickable, but documentation links all report"file not found"
.As a result, there is no combination that works anymore for Dockerized
hoogle-local
. This would work if--local --host '*'
addsfile/
leaders within documentation pages, as well as within search results.