Currently, last modification time is always displayed in GMT+0 which is a little confusing. I think that we should either:

• Write "xx-xx-xx xx:xx:xx (GMT)" to clarify, or
• Display time in the timezone of the client.

It's simple enough to do (I have ready-to-go build.rses from my other projects I can just plug in), just wondering if we should.

There's potential for the need to run the server with both http and https side by side, and by default http should be redirected to https. A new cli option should be added that will prevent the redirection, I suggest --no-https-redirect. Obviously, if https isn't running, this flag would have no effect

Nice pretty colours are pretty and nice. Some sort of highlighting should be added. The different elements of the log messages should be highlighted individually. For ease of understand what is going on with the colours, they should be defined in one concise location

Probably with some indicator that you can do it (overlay?).

HTTP defines PATCH in RFC5789. Support therefor would go a long way towards full write support.

Like timestamp at least

This should be the default, but have a cli flag to control if this is to be used or use hover text that can display the raw byte count

use nice pretty diagrams that represent folders or files types (a default icon for "it's a file" and maybe we can work on icons for other types of files, we may not... but maybe support the option)

We should try to find an RFC that actually defines how servers are meant to handle this and consider how modern browsers handle it as well. I think that strictly speaking, browsers do not ask for 'folders', they automatically append index.html... that might also just be a convention, I don't see any reason why it should have that name.

Asking for a folder might technically warrant some sort of 4XX response, as the client shouldn't have asked for a folder.

Also need to consider how to handle extensions, if the client asks for index.html but there is only an index.htm, do we return that instead?

When going down to physically smaller screens, the UI should adapt so that it is still nice looking.

yay for fluffy non precise issues :D

If certificates are not provided, but encryption requested, then self signed certifications should be generated and used automatically. Not sure if this is practical though.

Feature request: Ability to stream videos from random positions in the middle.

Expected behaviour

• Share a directory containing a big(ish) video file;
• Connect to the server with a browser (It should better be from a computer different than the one hosting the server to add some network latency);
• Click the video name; The browser will start loading and displaying the video;
• You will notice in the video progress-bar that the browser shows how much it has pre-fetched (downloaded);
• Jump (by clicking/tapping in the progress-bar) to a position in the video that is not loaded yet;
• The browser should start displaying the video from that position.

Observed behaviour

Jumping to the middle doesn't work with and without the -e flag. I tested it in my mobile's Firefox with a >2h video. It can't jump to positions that are not loaded:

• I can jump to positions in the video that was already loaded or pre-fetched by firefox. This is always the case with small files and when I use Firefox from the same laptop as the server since the file is ~instantly downloaded.
• What I can't do is jump to a position which is not yet loaded. For example, when I open a 2hours long video, it starts from 0h00. if I try to jump to 1h00, it will fail to do so and it will jump instead to 1min xy seconds (or wherever the download is so far).

From inspecting what http headers are sent when firefox tries to jump to a not-loaded position in this youtube video (the link should die soon), firefox sends few video-specific http-options, and the server responds respectively:

1st Request
===========

Host: r5---sn-hgn7zn7s.googlevideo.com
User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: video/webm,video/ogg,video/*;q=0.9,application/ogg;q=0.7,audio/*;q=0.6,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
Range: bytes=7798784-
Referer: https://r5---sn-hgn7zn7s.googlevideo.com/videoplayback?key=cms1&gir=yes&mime=video%2Fmp4&requiressl=yes&ratebypass=yes&dur=346.046&lmt=1484123052879736&source=youtube&clen=15053869&id=o-ANabftMGPfGu6vXOHu9TF_px2mY-v7HUAwzfaC8UZLYb&expire=1484193348&ei=46l2WM2VOsfycuTGo9AN&pl=17&ipbits=0&ip=41.109.236.221&sparams=clen,dur,ei,expire,gir,id,initcwndbps,ip,ipbits,itag,lmt,mime,mm,mn,ms,mv,nh,pl,ratebypass,requiressl,source,upn&signature=5C096A27A1D5D53A18742D85F324ECF71C482C2E.6D9B3D096D2DF27DDB8B2B677050721D92743F76&itag=18&upn=OURRDchDiSI&cmbypass=yes&redirect_counter=1&req_id=b284bf5a3f79a3ee&cms_redirect=yes&mm=30&mn=sn-hgn7zn7s&ms=nxu&mt=1484171710&mv=m&nh=IgpwcjAyLm1yczAyKg8yMTMuMTQ0LjE3Ni4yMjA
DNT: 1
Connection: keep-alive


1st response
============

Accept-Ranges: bytes
Alt-Svc: quic=":443"; ma=2592000
Cache-Control: private, max-age=21234
Connection: close
Content-Length: 7255085
Content-Range: bytes 7798784-15053868/15053869
Content-Type: video/mp4
Date: Wed, 11 Jan 2017 21:56:54 GMT
Expires: Wed, 11 Jan 2017 21:56:54 GMT
Last-Modified: Wed, 11 Jan 2017 08:24:12 GMT
Server: gvs 1.0
X-Content-Type-Options: nosniff

Middle request
==============

Host: r5---sn-hgn7zn7s.googlevideo.com
User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: video/webm,video/ogg,video/*;q=0.9,application/ogg;q=0.7,audio/*;q=0.6,*/*;q=0.5
Accept-Language: en-US,en;q=0.5
Range: bytes=11075584-
Referer: https://r5---sn-hgn7zn7s.googlevideo.com/videoplayback?key=cms1&gir=yes&mime=video%2Fmp4&requiressl=yes&ratebypass=yes&dur=346.046&lmt=1484123052879736&source=youtube&clen=15053869&id=o-ANabftMGPfGu6vXOHu9TF_px2mY-v7HUAwzfaC8UZLYb&expire=1484193348&ei=46l2WM2VOsfycuTGo9AN&pl=17&ipbits=0&ip=41.109.236.221&sparams=clen,dur,ei,expire,gir,id,initcwndbps,ip,ipbits,itag,lmt,mime,mm,mn,ms,mv,nh,pl,ratebypass,requiressl,source,upn&signature=5C096A27A1D5D53A18742D85F324ECF71C482C2E.6D9B3D096D2DF27DDB8B2B677050721D92743F76&itag=18&upn=OURRDchDiSI&cmbypass=yes&redirect_counter=1&req_id=b284bf5a3f79a3ee&cms_redirect=yes&mm=30&mn=sn-hgn7zn7s&ms=nxu&mt=1484171710&mv=m&nh=IgpwcjAyLm1yczAyKg8yMTMuMTQ0LjE3Ni4yMjA
DNT: 1
Connection: keep-alive


Response
========
Accept-Ranges: bytes
Alt-Svc: quic=":443"; ma=2592000
Cache-Control: private, max-age=21214
Connection: close
Content-Length: 3978285
Content-Range: bytes 11075584-15053868/15053869
Content-Type: video/mp4
Date: Wed, 11 Jan 2017 21:57:14 GMT
Expires: Wed, 11 Jan 2017 21:57:14 GMT
Last-Modified: Wed, 11 Jan 2017 08:24:12 GMT
Server: gvs 1.0
X-Content-Type-Options: nosniff

Pirate said he wanted them, so a definite addition, but I need a feature that's currently not in and am e-mailing the owner with feature requests, so don't hold up #55 with this, since it could take a long time.

HTTP defines DELETE in RFC7231. Support therefor would go a long way towards full write support.

If the server is running with https enabled, it should auto redirect any http requests to the https version

Running http should not come with the risk of you losing any data, and so the folder that it servers should be considered read-only.

However, to support methods such as POST, the server will need a place to write files to. By default a 'randomly' named folder should be created anywhere in the OS (ie /tmp/ ). This folder should then be deleted afterwards.

This folder should only be created when it is first required.

When the server starts up, it should also copy the details to the clipboard, this should be the IP for the machine, not 'localhost' so you can paste it into some chat easier

The server should default to hosting the current directory. There should be no need to explicitly pass this in via command line

I can generate an curl | sh-kind installer for Linux and a normal one for Windooze on respective CIs.

Rather than just the text, for the file/folder name itself, the link should be of a larger html element so that there is more to click. It should also have a hover effect that highlights what you are over so it's clear

I'll probably work on an image for it at some point... just need a default image to make things a bit prettier

The likes of 404 and 501 pages are all basically the same, the only difference is that message we would want to put into them. We are also likely to want to tweak things, like footer messages. As such, there should be a generic template file that we can pass in the string to display as the error message.

If the server can't secure the desired port, it should start to increment one at a time until it finds a free port to listen on. This can loop around from max port back to the lowest port that doesn't require privilege escalation. If it loops back to the starting port, it should print an error message and quit

Time-wise CPU&RAM is cheap, network is not. We can do magic and send compressed data via Encoding header.

Pulled latest from dev, when running http -h the temp-dir is listed as just this... (there should be a -t version as well)

--temp-dir Temporary directory. Default: $TEMP

¬_¬ maybe support them too? Might be best to get a suite of tests that assert some behavioural stuff. I think that non-linux OS support can stay secondary... but if we can avoid breaking features on non-linux, even if that means they don't get new stuff (like if getting file permissions is tedious on windows but trivial on linux)

I think that the directory listing should be reloaded after uploads in order to add the file to the directory listing.

Currently, when I upload I get no feedback on whether the file has been copied and I need to reload the page manually.

Get a service running that can listen on a tcp port read for requests. This should default to port 8000. For now, if the server can't start listening on this port, it will simply print a message explaining it can't use port 8000 and then quit

Can we get stuff like versioning and releasing builds magicked up? What about packaging? I't d be nice to not have to install from source. Signing builds? Automation!

The server doesn't decode shit like capi%20talism into capi talism, which seriously impairs its usefulness.

Petty issue really, but this should be wrapped in a

tag (personal preference more than anything). I would change it, but don't know if that's going to break the way the templates work, I doubt it would, but just encase.

Probably quite a bit involved in actually supporting this fully... well, if GET is supported fully, this should be easy... right?

We should follow symlinks by default, and have that turned off by using the corresponding flags. As this changes the default behaviour, this is considered a breaking change and so should bump the major version.

For example things like zips, compressed video files and images, etc. should not be encoded because you're actually losing network and time.

HTTP defines POST in RFC7231. Support therefor would go a long way towards full write support.

Rather than just a scrolling log of what actions are requested... perhaps a swish console could be started that can show the status of things like what folder is being hosted, where temp files are, the progress of any ongoing transfers.

This may be more than should be done in this project, perhaps a separate project can wrap this one to provide this console mode

The served pages for directory listings don't look good (especially in mobile)

• In mobile:
  • I need to both "zoom in" and "scroll" left and right which is not a very nice experience.
  • I need to click exactly on the link to send a request. This is especially hard on mobile. I mean: I'm used in many file managers to the behaviour of something similar to <a><div>Name, Last modified, Size</div></a> so that I can click anywhere in the box containing the file name to trigger a request.
• Both in desktop and mobile:
  • There is no way to change the sort order.

Google Drive is a good example of a professional-looking web-based file-browser. If you are using a desktop browser you get something like this:

And with a mobile phone you get (This can be accessed by using responsive mode in firefox and setting the user agent to: Mozilla/5.0 (Android 4.4; Mobile; rv:50.0) Gecko/50.0 Firefox/50.0):

and

Let's define the goals of this project

I think that it is good to write down:

• The functional specification: How exactly the served webpages are supposed to behave both on desktop and mobile. For example, I wouldn't suggest to replicate every feature of Google Drive but let's decide on which features we like to support.
• The technical specification: For example, serving a simple web page (usable by old browsers) but progressively enhanced by flexbox.

E.g. if orig size divided by encoded size is less than 1.1 we delete the cached file and mark the original as uncacheable.

While their href is ../, the link hint points to server root, and, indeed, it takes you there.
I'm on Firefox DevEdition Latest so it might just be it, or it might not. We need to confirm with more browsers.

Basically, just be able to accept a basic request from the client and respond with a 501 message. This does not need to care about the type of request, or the URI, or any details likes cookies of URI parameters. It simply needs to see the request was made, and send back a 404 to the client (it doesn't even need to be a 501 page)

Drag and drop is all well and good, but isn't clear. A form thing should be added to the directory listing pages which allows people to select a file and then upload them to the current folder.

Initially this can just upload one file at a time, but it can be 'upgraded' as per browser support so that you can upload multiple files and/or upload without requiring page refresh.

When I upload a directory using the current version, a 0 byte file is created and a no error is shown.

I expect either:

• getting an error (unimplemented feature) or
• that the feature works.

I tried uploading a directory to Google Drive with drag and drop on Firefox 50.0 and it worked correctly. Firefox 50.0 is the first firefox release to support this but chrome always did.

As to how to implement this feature, it is described here: https://wicg.github.io/directory-upload/proposal.html

• last modified date/time
• file size (basic byte count)
• group/user owner
• indication if 'thing' is directory or file

HTTP defines PUT in RFC7231. Support therefor would go a long way towards full write support.

The readme started off as a plan for a silly idea from me... but now it's an actual thing that works and stuff. It should be updated to show what functionality exists, what we roughly plan to add, what we decided not to do and most importantly, what cli options there are.

Like #7 but much easier to apply since we have raw strings that we can compress and most of the data we send should compress well.

Might be nice if we could also support encryption for this as well.

Would probably have to be done via a cli option to enable and require a path to the required certificate files. For now, probably just stick to the latest encryption standards, supporting older stuff can maybe done later if felt reasonable