As discussed with @mholt I have dropped the old LinkedPath function and
replaced it within the browse template with the new BreadcrumbMap
function. Visually it looks exactly the same as before, now the template
functionality is just more powerful.
Signed-off-by: Thomas Boerger <tboerger@suse.de>
In order to being able to really build a custom template for the browse
directive I have added another function to build even custom breadcrumb
paths. The other function `LinkedPath` is not that easy styleable as
this map function. That way we are able to build the breadcrumb path
matching different CSS frameworks like Bootstrap.
Signed-off-by: Thomas Boerger <thomas@webhippie.de>
Caddy recovers panics that occur in the middleware stack so this is not a risk to process termination. This way is also preferable to hiding the error. See 3faad41b43 (commitcomment-17035158)
Caddy expects websocket to be completely lowercase.
Some applications send websocket upgrade headers like the following:
`Upgrade: WebSocket`
This change allows all variations of websocket.
Right now it has a very simple configuration:
expvar /debug/vars
It will return a JSON object with memory statistics and the command line
used to start caddy, which are the two expvars that expvar registers by
default.
- The mime middleware used filepath where it should arguably use path.
- Changed the configuration to use a map instead of scanning an array
during every request. The map is static (after configuration), so
should be fine for concurrent access.
- Catch duplicate extensions within a configuration and error out.
- Add tests for new error case.
fastcgi's ServeHTTP method originally returned the correct value (0) in
b51e8bc191. Later, I mistakenly suggested
we change that to return the status code because I forgot that status
codes aren't logged by the return value. So fastcgi broke due in
3966936bd6 due to my error.
We later had to try to make up for this with ugly Content-Length checks
like in c37ad7f677. Turns out that all we
had to do was fix the returned status here back to 0. The proxy
middleware behaves the same way, and returning 0 is correct. We should
only return a status code if the response has not been written, but with
upstream servers, we do write a response; they do not know about our
error handler.
Also clarifed this in the middleware.Handler documentation.
