Add fields.has

[elliottt]

It's not currently possible to test whether a field-key is present in a fields, as our return value of an empty list could mean either that the header was missing, or had no value. Add the fields.has method to give an unambiguous way to test for field-key presence in a fields.

Fixes #82

[pchickey]

This comment is now obsolete

Before we land this I believe we need to make this change in structure consistent in the other field methods:

• from-list can wrap field-value in option
• set can wrap list<field-value> in option
• entries can wrap field-value in option.

[elliottt]

After some discussion, I think the right change here is instead to add the fields.has function that @guybedford mentioned in #82. This addresses the immediate concern of being able to test if a header is present in the fields, and requires no other spec changes.

[guybedford]

Could we implement both changes?

[pchickey]

+1 to adding fields.has. I appreciate that we are able to avoid changing the types on any other fields methods by using "" to represent the empty value.

[elliottt]

Could we implement both changes?

I think that since we're using "" to mean present-but-empty, this would mean that a return value of [] indicates that the key is missing. I've updated the docs on fields.get to indicate that [""] is present-but-empty, and [] is missing.

[guybedford]

This sounds reasonable in equating the empty string with an empty header value. This then makes it easy to set an empty header and compose it the other functions like append and set as @pchickey mentions in #91 (comment). In the WhatWG implementation var h = new Headers({ a: '' }); h.append('A', ''); h.get('a'); returns " , ", which seems highly unnecessary so I do prefer this approach for consistency.

Edit: I think this approach still allows multiple empty header values just fine in that append('a', '') can be called twice, so it is whatwg consistent even and more so than with a get option<>.