I'm working on adapting another project that makes use of this library to emulate the TLS fingerprint of chrome. In particular, I'm trying to establish a WebSocket connection, which the library doesn't support currently. I'm running into an issue (seemingly) stemming from this library- during the course of establishing my WS connection, I need to call functions that expect a value of type net/http. When I try to use fhttp in its place, the code doesn't seem to type check.

As an example, here's some code that produces an issue:

connBackend, resp, err := dialer.Dial(pageURL, req.Header)

I encounter a similar problem anywhere that a vanilla net/http property is expected, but an fhttp property is supplied.

What I have tried:

• Casting the req.Header as a net/http.Header - this works for this case, but later on when I need to pass along the ResponseWriter or something more complex, it doesn't:

connPub, err := upgrader.Upgrade(w, req, upgradeHeader)

^ Here I can convert upgradeHeader to the desired type but not the first two. I feel like this isn't the right approach- fhttp should be a drop in, no? Is there any workaround?

This Pull Request includes two minor changes, as shown by the two commits that form it.

The first change involves the introduction of a RWMutex in header.go, as @ShrimpAIO reported a Race Condition due to SortedKeyValues() and writeSubset() both trying to access the exclude map at the same time when running several tasks at once, resulting in a Fatal Error ("concurrent map read and map write").

The second change mainly involves the modification of README.md, formatting the document following Google's Markdown Style Guide. Additionally, the Note at the beginning of the file was commented out, as should only be used in @zMrKrabz's original repository. Finally, some spelling errors were corrected, including one pointed out by @0xflotus in this Open Pull Request.