Fix Authorization header generation

[ERobsham]

Fixes Authorization header generation to include the query parameters (if present).
This brings the implementation inline with MacOS, and fixes digest auth with certain picky services.

Tested these changes against the IC Realtime ORB camera I was having issues with in #497, and our application successfully authenticated with this fix.

[ERobsham]

It looks like the one failing check is caused by an unrelated bug in libdispatch

[rfm]

The original implementation here was based on RFC2617, which allowed (in section 3.2.1) the URI field to be either absoluteURI or abs_path (and abs_path was chosen, probably because it's simpler), where abs_path does not include the query string.

However, I agree with your diagnosis that the latest/current RFC7616 (section 3.4) has changed this, and abs_path is no longer allowed because that choice of two possibilities is replaced by 'Effective Request URI', and the old abs_path is not valid as an effective request uri.

It seems to me that your patch is a partial but incomplete fix, because my reading of the RFCs is that the new value should be a complete absolute URL, not just path plus query string. As such I think GSHTTPAuthentication should probably be changed to use the scheme, host and port information from the protection space to construct a full URL. Does that work for your application?
I guess there is also a small chance that the format demanded by the new RFC may not work with some old servers, but we can probably ignore that (or add some option to control the format if it does turn out to be a problem).

[rfm]

That being said, I just looked at the curl source code (I think Apple use libcurl).
That doesn't seem to use a full URL (unless higher level calling code is constructing it and passing it in the path argument to the authorisation header generation), however it does have an option to control whether query string is used or not (it truncates the path at the question mark if it is talking to a certain class of servers).

[ERobsham]

The RFCs are a bit dense, so I definitely was skimming a bit (and probably biased myself by looking at the raw packet captures from the MacOS implementation), but I was interpreting 'Effective Request URI' as:
origin-form = absolute-path [ "?" query ] where absolute-path = 1*( "/" segment )

So I think we're good without any of the scheme / host / port etc included in that URI.

---

And I hadn't checked into the libcurl code before, but I see what you mean with that 'if IE style' block.

If thats something we'd want to account for here, do you have any suggestions on how we'd want that exposed in the API.