Skip to content
This repository has been archived by the owner on Oct 29, 2021. It is now read-only.

traceapp: take a base URL parameter in New #162

Merged
merged 7 commits into from
May 10, 2016
Merged

traceapp: take a base URL parameter in New #162

merged 7 commits into from
May 10, 2016

Conversation

emidoots
Copy link
Member

This change requires that users of traceapp pass a base URL parameter. This is
needed in order to create absolute URLs to e.g. traces for permalinks. Prior to
this change, we would get this base URL via github.com/gorilla/mux.Route.URLTo
but this notably enforces an HTTP-only scheme (source code here)
which prevents Appdash permalinks from working on HTTPS hosted systems. This is
fixed with this change, by requiring an explicit base URL to be given as a
parameter.

Verified as working manually via the examples.

This change requires that users of traceapp pass a base URL parameter. This is
needed in order to create absolute URLs to e.g. traces for permalinks. Prior to
this change, we would get this base URL via `github.com/gorilla/mux.Route.URLTo`
but this notably enforces an HTTP-only scheme ([source code here](https://github.com/gorilla/mux/blob/master/route.go#L473))
which prevents Appdash permalinks from working on HTTPS hosted systems. This is
fixed with this change, by requiring an explicit base URL to be given as a
parameter.
app := &App{Router: r, Log: log.New(os.Stderr, "appdash: ", log.LstdFlags)}
// Validate the base URL and use the root path if none was specified.
if base.Scheme == "" || base.Host == "" {
return nil, fmt.Errorf("appdash: base URL must contain both scheme and port, found %q", base.String())
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you are checking host is non-nil, but then complain about the port missing.

Also, can we not just trust that the user passed in a reasonable URL? We don't actually use the scheme or host specifically right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch, I've changed port to host.

Also, can we not just trust that the user passed in a reasonable URL? We don't actually use the scheme or host specifically right?

Not entirely. The whole point of this change is that we are explicitly using a scheme and host in order to link to trace permalinks. This is because traceapp really can't know where it is hosted unless someone tells it.

We could omit the check for scheme and host.. but it would make it a lot easier for users to shoot themselves in the foot.

@keegancsmith
Copy link
Member

If base is nil, could we not resort to previous behaviour? This is just a suggestion to simplify the API usage. But if you want to force people to think of the base url, then this is good.

I have a few inline comments, but otherwise LGTM

emidoots added 3 commits May 9, 2016 17:06
… on --http addr).

This causes `appdash serve` to always choose a better default for `--url` when not
specified. Prior to this it would choose a hard-coded default which matched the `--http`
default, but that default would not work when changing `--http`.
@emidoots
Copy link
Member Author

If base is nil, could we not resort to previous behaviour? This is just a suggestion to simplify the API usage. But if you want to force people to think of the base url, then this is good.

At an initial glance this would seem like a simplification, but it's actually a bad idea in disguise. It's actually very important that users specify the right base URL otherwise some things will break (e.g. trace permalinks, certain JS/CSS/etc file includes, etc) and others won't. It's not pretty, and worse might not always be obvious in the future, so best to force the user to think about what exactly that parameter really means.

@emidoots emidoots merged commit ffef430 into master May 10, 2016
@emidoots emidoots deleted the sg/baseurl branch May 10, 2016 01:28
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants