Reorganize $DENO_DIR/deps folder and split by protocol

[kevinkassimo]

Supposed to close #930

Reorganize $DENO_DIR/deps folder by creating protocol specific subdirectories.
e.g.

import "http:https://a.com/a.ts"
import "https://b.com/b.ts"

should create folder $DENO_DIR/deps/http/a.com and $DENO_DIR/deps/https/b.com

I feel this might be also a necessary step for Deno to probably support other protocols in the future.

There is currently no test on TS side. To add tests, I hope I could get sample code from #930 (comment) to be hosted somewhere stable.

[hayd]

perhaps should do:

"http" => ...
_ => unimplemented!();

[kevinkassimo]

Good idea.

[kevinkassimo]

@ry Is this change of design appropriate? I might want to settle this PR sooner, or close it, or explicitly let someone else take care of it (having some urgent academic business need to deal with, and might have to pause my contribution to deno for about 1 month)

[ry]

@kevinkassimo Sorry for the slow response - I'm hesitating on this because it's not solving an actual bug. The point of this is that http and https could be serving different files - and therefore we should cache them separately? While this is true - it seems like a very bad idea for a website to have this behavior - and I'm not sure we should work around that...

[kevinkassimo]

@ry I feel http and https might be a special case here that could share the same cache (e.g. I could make deps/https a symlink to deps/http), but the separation of cache folder might be important considering extensibility for other protocols (ftp, ipfs or more)

Otherwise, we might have to use other sorts of metadata to store the original protocol used for script retrieval.

[Macil]

HTTP and HTTPS could easily serve different files if there's a man-in-the-middle attack. Imagine you're on some crappy free wifi that injects some advertising code into any javascript files downloaded over http, you run one insignificant sandboxed software project using deno that imports http:https://foo..., and then run a different project in deno with a bunch of --allow flags that imports https://foo.... If the latter process re-uses the cache of http:https://foo..., then you've just ran malicious code with privileges. Even if you checked the latter project's code fully prior to running it with privileges, you wouldn't be able to spot the issue.

Also, if a server only supports one protocol or the other, it would be really easy to fool yourself: imagine you write a script that imports http:https://bar..., it works, you realize HTTPS is better so you change your project's code to import https://bar..., run it, it works (because it grabbed the file from the shared cache), you commit it, but it turns out the server for that url doesn't support HTTPS and your project no longer works from an empty cache and you never figure this out unless you try clearing your cache or someone else tells you.

[hayd]

There is simplicity in an injective/invertible cache map, being able to know precisely where a cached file was from. The cost of downloading the same file referenced with http and https twice seems worth it.

I had thought the bug this was solving was relative imports inside ts, which requires building the url from the cache location..?

It would be good if this code could be generic over all schemes.

[ry]

LGTM
I was dragging my feet on this, because I don't like the added complexity to the ~/.deno tree, but I acknowledge the correctness. Thanks Kevin.