relative paths for static assets

[skabbes]

I would like to expose this tool as a page on an admin site as admin.site.com/db. However, this is very hard since the client side code uses absolute paths to assets.

My approach would be something like this:

// pseudocode
if (path matches /^\/db\/(.*)$/ ) {
  authenticate request
  proxy request to pgweb/$1
} else {
  run regular site
}

But this is currently impossible, because index.html references all of its required assets in an absolute sense. I believe that all that would be required would be make all client side code & assets reference root as ./ instead of /.

The serverside (API) code should work just fine without change, since the proxy will strip the /db from the beginning of each request.

If this a patch that you'd accept if I were to write it?

[sosedoff]

Sure, if you have a patch that does not introduce any breaking changes i'd gladly accept it.

[sosedoff]

On the other hand i would probably prefer a solution that changes the path prefix for the whole application. That would work better IMO. Thoughts?

[skabbes]

In short: I don't think it adds any additional value. To elaborate...

I think the value of relative paths is being able to run pgweb alongside another web app (so pgweb doesn't need an entire subdomain). However, to do that, you're going to need an HTTP reverse proxy in front of it anyway (since how else would you share the same tcp port)?

I could see 3 possible scenarios here to run Pgweb next to another web app.

1.
INTERNET ----> NGINX ---  /db/* ---- > PGWEB
                 \--- * ---> OTHER WEB APP

2.
INTERNET ----> OTHER WEB APP ---  /db/* ---- > PGWEB
                     \---- * ---> OTHER WEB APP

3.
INTERNET ----> PGWEB ---  /db/* ---- > PGWEB
                   \---- * ---> OTHER WEB APP

For solutions 1 and 2, I think there is absolutely no value in adding a prefix in Go, since every single reverse proxy basically provides this out of the box. (This is so common, in fact, I think it might be a lot of extra work to leave the prefix on).

For solution 3, I suppose it would be useful - but I don't know if I would recommend proxying all your web traffic through pgweb :)

[sosedoff]

I don't necessarily agree that having a url prefix does not provide any value. Having a url prefix baked into the app's makes it super easy to use with software like nginx.

I pushed a new git branch url-prefix that implements url prefix for pgweb, you can compile the source code from that branch and then start pgweb with --prefix=db/.

For nginx, then you can configure pgweb as follows:

upstream pgweb {
  server 127.0.0.1:8081;
}

server {
  # other stuff
  # ...

  # proxy any database stuff directly to pgweb
  location /db {
    proxy_pass http://pgweb;
  } 
}

If that works for you - great, otherwise please provide your own solution and will gladly review and accept the patch for the feature in question. Cheers.

[skabbes]

Ah, cool. I think you can also put:

location /db/ { proxy_pass http://pgweb; } 

(Note the trailing slash on /db/) and it will strip "db" off the proxied request. One extra character for no additional code in golang.

— Sent from Mailbox

On Fri, Feb 19, 2016 at 7:30 PM, Dan Sosedoff notifications@github.com wrote:

I don't necessarily agree that having a url prefix does not provide any value. Having a url prefix baked into the app's makes it super easy to use with software like nginx. I pushed a new git branch url-prefix that implements url prefix for pgweb, you can compile the source code from that branch and then start pgweb with --prefix=db/. For nginx, then you can configure pgweb as follows:

upstream pgweb {
  server 127.0.0.1:8081;
}
server {
  # other stuff
  # ...
  # proxy any database stuff directly to pgweb
  location /db {
    proxy_pass http://pgweb;
  } 
}

If that works for you - great, otherwise please provide your own solution and will gladly review and accept the patch for the feature in question. Cheers.

Reply to this email directly or view it on GitHub: https://github.com/sosedoff/pgweb/issues/131#issuecomment-186497480

[skabbes]

But either way works for me, thanks so much for doing this!!

— Sent from Mailbox

On Fri, Feb 19, 2016 at 7:30 PM, Dan Sosedoff notifications@github.com wrote:

I don't necessarily agree that having a url prefix does not provide any value. Having a url prefix baked into the app's makes it super easy to use with software like nginx. I pushed a new git branch url-prefix that implements url prefix for pgweb, you can compile the source code from that branch and then start pgweb with --prefix=db/. For nginx, then you can configure pgweb as follows:

upstream pgweb {
  server 127.0.0.1:8081;
}
server {
  # other stuff
  # ...
  # proxy any database stuff directly to pgweb
  location /db {
    proxy_pass http://pgweb;
  } 
}

If that works for you - great, otherwise please provide your own solution and will gladly review and accept the patch for the feature in question. Cheers.

Reply to this email directly or view it on GitHub: https://github.com/sosedoff/pgweb/issues/131#issuecomment-186497480

[sosedoff]

Implemented on master. Feel free to reopen if you find any issues

[andreibancioiu]

Currently, the solution proposed by @skabbes works for me, but the solution using --prefix=... does not (I receive a 404 error from the Go application - not from nginx).

This is problematic:

pgweb_linux_amd64 --listen=9090  --prefix=pgweb/

nginx config:

location /pgweb {
    proxy_pass http://127.0.0.1:9090/;
}

Anyway, running without the prefix argument, but with the trailing slash in the location section seems fine:

location /pgweb/ {
    proxy_pass http://127.0.0.1:9090/;
}

[sosedoff]

@andreibancioiu when i start pgweb with --prefix=pgweb/ i can access the url with that prefix just fine. did you verify that by accessing http://localhost:9090/pgweb? if it does not work you will get 404 page.