issue_comments

Y, thank you to both of you!

Great, really happy I could help! Reverse proxies get tricky.

Fantastic!

+1

Yep! Fixes it. If I navigate to https://corpora.tika.apache.org/datasette, I get a 404 (database not found: datasette), but if I navigate to https://corpora.tika.apache.org/datasette/file_profiles/, everything WORKS!

Thank you!

@henry501 it looks like you spotted a bug in the documentation - I just addressed that, the fix is now live here: https://docs.datasette.io/en/latest/deploying.html#running-datasette-behind-a-proxy

@tballison I think that's the solution! It looks like you need to use this in your config:

ProxyPass /datasette http://127.0.0.1:8001/datasette

Instead of this:

ProxyPass /datasette http://127.0.0.1:8001/

Give that a go and let me know if it fixes it.

I found this issue while troubleshooting the same behavior with an nginx reverse proxy. The solution was to make sure I set:

proxy_pass http://server:8001/baseurl/ instead of just:

proxy_pass http://server:8001 The custom SQL query and header links are now correct.

Could you try removing the ProxyPassReverse /datasette http://0.0.0.0:8001 line?

My hunch is that ProxyPassReverse is rewriting some of the links in the HTML (or maybe in the HTTP headers) in a way that breaks things.

Normally you would need ProxyPassReverse to compensate for the underlying application being unable to rewrite its links - but Datasette's base_url setting causes Datasette to rewrite all of the links for you, so ProxyPassReverse should be unneccessary.

OK that is really weird. I'll have another go at replicating this locally.

I can't imagine this helps (esp. given your point about potential rewrites), but you can see that /datasette/ was correctly added to the sql form, but not to the "export-links"

I don't think this fixes it:

grep -R datasette . ./sites-available/000-default.conf: ProxyPass /datasette http://127.0.0.1:8001/ ./sites-available/000-default.conf: #ProxyPassReverse /datasette http://127.0.0.1:8001/ ./sites-available/corpora-le-ssl.conf: ProxyPass /datasette http://0.0.0.0:8001 ./sites-available/corpora-le-ssl.conf: #ProxyPassReverse /datasette http://0.0.0.0:8001 ./sites-enabled/corpora-le-ssl.conf: ProxyPass /datasette http://0.0.0.0:8001 ./sites-enabled/corpora-le-ssl.conf: #ProxyPassReverse /datasette http://0.0.0.0:8001

And I confirmed that I actually restarted the server. :rofl:

https://corpora.tika.apache.org/datasette/file_profiles

Anything we can do to help debug this? Thank you, again!

We're using mod_proxy.

I don't think we are, but I'll check with Maruan.

I think this is the relevant part of our config?

``` Alias "/base/" "/usr/share/corpora/" <Directory "/usr/share/corpora/"> Options +Indexes -Multiviews AllowOverride None </Directory>

ProxyPreserveHost On

ProxyPass /datasette http://0.0.0.0:8001 ProxyPassReverse /datasette http://0.0.0.0:8001

</VirtualHost> ```

I have a hunch that there may be some extra configuration in play here - could Apache itself be rewriting some of the links using mod_proxy_html?

@tballison could I see the section of your Apache config that configures the proxying to /datasette/?

My headers aren't clickable/sortable with custom sql, but I think that's by design.

In the default view, https://corpora.tika.apache.org/datasette/file_profiles/file_profiles, ah, y, now I see that the headers should be sortable, but you're right the base_url is not applied.

base_url works with "View and Edit SQL" and with "(advanced)"

As you point out, does not work with the export csv, json, other or with the "Next page" navigational button at the bottom.

I'm starting this with docker like so:

docker run --name datasette -d -p 8001:8001 -vpwd:/mnt datasetteproject/datasette datasette -p 8001 -h 0.0.0.0 /mnt/file_profiles.db --config sql_time_limit_ms:120000 --config max_returned_rows:100000 --config base_url:/datasette/ --config cache_size_kb:50000

I'm not doing any templating or anything else custom.

Apropos of nothing, I swapped out a simpler db, so this query should now work:

https://corpora.tika.apache.org/datasette/file_profiles?sql=select%0D%0A++*%0D%0Afrom%0D%0A++file_profiles+fp%0D%0Alimit%0D%0A++10

Here's where url_csv comes from: https://github.com/simonw/datasette/blob/11eb1e026f3d84cb771f8d6e204939cbaee130cd/datasette/views/base.py#L542-L545

The sort headers are generated by this template code: https://github.com/simonw/datasette/blob/5eb8e9bf250b26e30b017d39a392c33973997656/datasette/templates/_table.html#L11-L15

The export links use this code:

https://github.com/simonw/datasette/blob/5eb8e9bf250b26e30b017d39a392c33973997656/datasette/templates/table.html#L134

https://github.com/simonw/datasette/blob/5eb8e9bf250b26e30b017d39a392c33973997656/datasette/templates/table.html#L180-L201

@tballison is there any chance you're running any custom templates in that installation? I'm really confused as to why I can't replicate the bug.

Hmm... it's not just the .csv and .json export links - it's the column headings (which can be clicked to change the sort order) as well. Here's an extract of the HTML from that page: ```html

This data as json, CSV ( advanced)

But here's something _really_ weird - the links to the individual rows DO include the `/datasette/` prefix:html

The navigation bar on that page is correct too:html

home / corpora-metadata

`` I've also been unable to replicate this in my own local environment, runningdatasette fixtures.db --config base_url:/datasette/`.