Broken when behind a proxy with a path other than /

[smola]

I'm trying to access a bblfsh-web instance with Kubernetes proxy, which generates a URL like this: http://localhost:8080/api/v1/namespaces/mynamespace/services/bblfsh-web-bblfsh-web/proxy/

Since all assets as well as the API are referenced as absolute paths, this breaks the logo image as well as all API calls. For example, clicking on parse will give a 404 error, since it tries http://localhost:8080/api/parse.

[se7entyse7en]

I'm currently working on a solution that fixes this issue, but it works at build time. That's because it needs to modify the homepage attribute of the package.json file that is used during the build of index.html.
Hence for each path other than root on which we want to run the server we need to build a docker image.
Does this approach satisfy our needs?

[smacker]

@se7entyse7en you already can change api url by using SERVER_URL env variable during build time.
But it doesn't solve the issue.

[se7entyse7en]

@smacker yup, in fact what I've done so far:

1. add a -root-path (default /) that is used as a prefix for each urls that are mounted to the server,
2. modified the Makefile in order to build against a specified ROOT_PATH passed as env var.

To make things easier I tested it using a simple nginx configuration instead of Kubernetes proxy, and the fix is working fine. I just have to fix some little issues. WDYT?

[smacker]

1. Build time is a bad solution. We release docker image with already built static there. You may take a look at gitbase-web or lookout-web to see how to change server url in runtime (on server start).
2. @smola will give you a better answer about his use case but usually, if you access service through proxy you can't hard-code configuration for that proxy on server side. Because a) result urls can be different for different users and b) because you still want server to work without any proxy

[se7entyse7en]

1. I also think that runtime solution would be the best fit, I'm gonna take a look at the other repos you mentioned in order to see how this has been achieved then.

2. Yup, in fact I haven't hardcoded the root path, but it has to be specified when building the image. Just to be clearer here how I currently build the image:

    ROOT_PATH="/bblfsh/" make build && docker build -t bblfsh/web 
   

where in Makefile there's the following "trick"

front-build: dependencies-frontend
ifneq ($(ROOT_PATH), /)
    	sed -i.bak 's#\("name": "bblfsh-web",\)#\1"homepage": "$(ROOT_PATH)",#g' package.json && rm package.json.bak
endif
    	GENERATE_SOURCEMAP=false REACT_APP_ROOT_PATH=$(ROOT_PATH) REACT_APP_SERVER_URL=$(SERVER_URL) $(YARN) build
    	git checkout -- package.json

build: front-build assets
    	@echo

The problem is that this solution requires one image per root path (not that scalable). The only thing that requires this is how the script tag is injected by yarn in the index.html: it uses the homepage key of the package.json to build the src of the tag. Maybe there's the possibility to modify how that works. But if this has been already solved in another projects I'm gonna check them first 👍

[smola]

Isn't it possible to just use relative URLs? That way the web would work both if accessing directly or through the proxy.

Otherwise, setting the URL as a runtime parameter would also work. As @smacker said, build time is not an option, since this will be set by src-d/engine or a Helm chart at deploy time based on the official Docker image.

[smacker]

@smola I believe we can use relative URLs here. We still need env variable (at least for development when we run frontend and API on different ports). But in production image, we can set it as ./.

Though it's not as simple as just changing current default :)

[se7entyse7en]

Okay, I'm gonna dig in deeper then and try making it work with relative urls. Thanks guys!