Set file name in HTTP response header

[amandasaurus]

If you're sharing a single file, it would be nice if the filename was included in the HTTP response headers, so that things weren't saved as index.html. Content-disposition header is the one

[mnalis]

(Update: added --trust-server-names to wget command line for reproducible results)

Hm, "Share via HTTP" v2.0.8 at least does not have that problem here. What client are you using, and can you capture or see network request (with for example wireshark or similar) ?

For me, it redirects to URL containing filename, which then of course downloads as that filename. For example:

$ wget --trust-server-names --server-response 192.168.9.102:9999
--2019-01-11 20:28:50--  http://192.168.9.102:9999/
Connecting to 192.168.9.102:9999... connected.
HTTP request sent, awaiting response...
  HTTP/1.0 302 Moved Temporarily
  Content-Length: 1331914
  Date: Fri, 11 Jan 2019 20:28:52 GMT+01:00
  Connection: close
  Server: ShareViaHttp 2.0.8
  Location: IMG_20190108_122527.jpg
  Expires: Tue, 03 Jul 2001 06:00:00 GMT
  Cache-Control: no-store, no-cache, must-revalidate, max-age=0
  Cache-Control: post-check=0, pre-check=0
  Pragma: no-cache
Location: IMG_20190108_122527.jpg [following]
--2019-01-11 20:28:50--  http://192.168.9.102:9999/IMG_20190108_122527.jpg
Connecting to 192.168.9.102:9999... connected.
HTTP request sent, awaiting response...
  HTTP/1.0 200 OK
  Content-Length: 1331914
  Date: Fri, 11 Jan 2019 20:28:52 GMT+01:00
  Connection: close
  Server: ShareViaHttp 2.0.8
  Content-Type: image/jpeg
Length: 1331914 (1,3M) [image/jpeg]
Saving to: ‘IMG_20190108_122527.jpg’

IMG_20190108_122527.jpg                         100%[======================================================================================================>]   1,27M  1,26MB/s    in 1,0s

2019-01-11 20:28:51 (1,26 MB/s) - ‘IMG_20190108_122527.jpg’ saved [1331914/1331914]

Same thing if I do it from firefox or other browsers.

[toofar]

I'm seeing this too.

$ wget --server-response http://phane.local:9999/
--2023-09-02 16:24:02--  http://phane.local:9999/
Resolving phane.local (phane.local)... 192.168.0.221
Connecting to phane.local (phane.local)|192.168.0.221|:9999... connected.
HTTP request sent, awaiting response...
  HTTP/1.0 302 Moved Temporarily
  Content-Length: 3226490
  Date: Sat, 02 Sep 2023 16:24:02 GMT+12:00
  Connection: close
  Server: ShareViaHttp 2.0.14
  Location: IMG_20230902_160619.jpg
  Expires: Tue, 03 Jul 2001 06:00:00 GMT
  Cache-Control: no-store, no-cache, must-revalidate, max-age=0
  Cache-Control: post-check=0, pre-check=0
  Pragma: no-cache
Location: IMG_20230902_160619.jpg [following]
--2023-09-02 16:24:02--  http://phane.local:9999/IMG_20230902_160619.jpg
Connecting to phane.local (phane.local)|192.168.0.221|:9999... connected.
HTTP request sent, awaiting response...
  HTTP/1.0 200 OK
  Content-Length: 3226490
  Date: Sat, 02 Sep 2023 16:24:02 GMT+12:00
  Connection: close
  Server: ShareViaHttp 2.0.14
  Content-Type: image/jpeg
Length: 3226490 (3.1M) [image/jpeg]
Saving to: ‘index.html’

index.html          100%[===================>]   3.08M  5.03MB/s    in 0.6s

2023-09-02 16:24:03 (5.03 MB/s) - ‘index.html’ saved [3226490/3226490]

And with curl:

$ curl -LO http://phane.local:9999/
curl: Remote file name has no length
curl: (23) Failed writing received data to disk/application

[mnalis]

Ah, yes, sorry about that. wget does need --trust-server-names in order to trust server names (which is configured site-wide in my wget example, but is indeed not the upstream default). Then I believe it will work for you @toofar as it does for me in my example. (Note: I've updated that post now to include that option)

---

As for curl, it seems to be its deficiency? I guess it only looks for filename in the original (user-specified on command line) URL, and not in URL of final redirect. I don't know if curl has separate option for that, perhaps? If not, it might be suggested at curls issue tracker if it isn't already.

Also the error curl: Remote file name has no length seems to ignore that final file in redirect list has Content-Length: 3226490; so curl seems confused when following HTTP redirects? (or perhaps I'm missing a reason why it seems to disregard that header?) It seems that if you try to get final URL manually (curl -LO http://phane.local:9999/IMG_20230902_160619.jpg in your example) than it works just fine and detects name and length normally. It is only when it follows HTTP redirect to that same file, that it fails

Just chalk it up as one more reason I prefer wget to curl :smile:

---

As far as shareviahttps is concerned, perhaps it could probably be made more compatible by including Content-Disposition: attachment; filename="example.jpg" header in final URL, but note that it comes with strings attached (e.g. you could no longer see picture in browser by opening e.g. http://192.168.0.1:9999/, but it would force the image to be downloaded, and you to use external program to see it; so I'm not sure if that would be good idea (or perhaps such behaviour should be configurable in preferences?)

[mnalis]

I've looked it up, and it seems to be on curl TODO list under 18.17, reported under https://github.com/curl/curl/issues/1241 (and https://github.com/curl/curl/issues/6880)

So I'd suggest sticking with wget until (and if) curl chooses to implement it. :man_shrugging: