php-proxy | A PHP proxy to circumvent JavaScript cross-domain policies | Proxy library

What you describe will not work. While PHP does have the ability to create a TCP server, a proxy server in particular must already be running and listening for connections before a client tries to connect to it, and hosting providers execute a PHP script only on an as-needed basis whenever a client requests the script via the HTTP/S protocol, running the script only for the duration of that request. For what you want, you need a dedicated server running your PHP application separate from a web server. You won't get that with a hosting provider.

There are a number of substantive differences between cd path; git command and git --work-tree=path command. Some or all of these differences can be made to vanish depending on additional parameters and/or environment variables.

It's important to realize that Git has three (not just two) key items that it must work with at almost all times. These are:

• The repository itself (the repo database of name-to-hash-ID pairs, such as master representing commit e3331758f12da22f4103eec7efe1b5304a9be5e9 or whatever other hash ID, plus the object whose ID is that big ugly hash ID string). The repository typically lives in a directory named .git at the top level of the work-tree. This is the git directory ($GIT_DIR).

• The index, which indexes and caches (hence its two names index or sometimes cache) the work-tree, and acts as a storage location (hence its third name, staging area) for updated files (really, pathname to blob hash ID translations) when you intend to build a new commit. The index is mostly a file: .git/index. As you can see from this path name, by default, the index file lives within the repository. However, it has its own separate control variable, $GIT_INDEX_FILE. It simply defaults to $GIT_DIR/index.

• The work-tree holds files in their uncompressed format. Files make their way into the work-tree by being extracted from a commit into the index, and then from the index (where they're still compressed and in Git-only format) into the work-tree. The work-tree may also hold additional files that are not found in the index. Such files are unstaged. An unstaged file may or may not be ignored (a staged file, i.e., one whose pathname appears in the index, is by definition never ignored).

The work-tree is normally just the current working directory, or derived from the current working directory by walking upwards (.., then ../.., and so on) to find the first place that contains a .git repository directory. This means that cd path; git ... searches for the work-tree starting from wherever you have landed.

If there are no overrides, having found the work-tree and hence the .git directory, Git now knows where $GIT_DIR is and where to find the index file. But if you provide an override, using git --work-tree=path or by setting the environment variable $GIT_WORK_TREE, Git will look there for the work-tree, and look in the current directory (or .. and then ../.. and so on) for the repository directory.

If you provide a --git-dir=path override, or set the environment variable $GIT_DIR, Git will look there for the repository directory, regardless of any setting or lack of setting for the work-tree.

(Note: --git-dir and --work-tree are actually implemented by having the git front end set the environment variables. Hence if you set both, the flag argument overrides the environment setting for the duration of the Git command, including any subprocesses that Git itself runs.)

IF you provide a $GIT_INDEX_FILE override via the environment, Git will look there for the index file, regardless of any setting or lack of setting for $GIT_DIR.

Any of these settings can be an absolute path—starting with / on Unix-like systems, or using a drive letter on sillier systems—or a relative path. An absolute path overrides the current working directory, while a relative path starts from the current working directory.

Hence the exact contents of any of these arguments or environment variables matter a great deal. For instance, running:

Scripts like that won't be able to proxy streaming media from other sites. You'll only be able to proxy the standard HTTP requests and assets. Your easiest bet is to run a VPN to get around any DNS or network blocks.

I'm not a huge fan of Node.js, however it's much better at streaming and asynchronous code, so take a look at this repo: https://github.com/licson0729/node-YouTubeStreamer