fetch: Drop Headers from HeadersInit typedef declaration.

fetch: Drop Headers from HeadersInit typedef declaration.

This finally aligns our typedef with the version in the spec. We can do so
now that our bindings code can convert any iterable object into a sequence.

The Headers::FillWith(const Header*, ...) overload has been kept though, as
it is used by other classes that may need to fill a Headers object with
another existing one (when initializing a Request object, for example).

BUG=705490
R=falken@chromium.org,mkwst@chromium.org,tyoshino@chromium.org,yhirano@chromium.org

Review-Url: https://codereview.chromium.org/2854613002
Cr-Commit-Position: refs/heads/master@{#468595}
Committed: https://chromium.googlesource.com/chromium/src/+/37b22b3ee932500caa379e06b0a170cc164c8d03

[Raphael Kubo da Costa (rakuco), 2017-05-01 10:49:19]

PTAL. This depends on https://codereview.chromium.org/2840193002/

[Raphael Kubo da Costa (rakuco), 2017-05-01 10:49:26]

The CQ bit was checked by raphael.kubo.da.costa@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2017-05-01 10:49:32]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-01 11:17:40]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-01 11:17:41]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Raphael Kubo da Costa (rakuco), 2017-05-01 12:11:28]

Description was changed from

==========
fetch: Drop Headers from HeadersInit typedef declaration.

This finally aligns our typedef with the version in the spec. We can do so
now that our bindings code can convert any iterable object into a sequence.

The Headers::FillWith(const Header*, ...) overload has been kept though, as
it is used by other classes that may need to fill a Headers object with
another existing one (when initializing a Request object, for example).

R=mkwst@chromium.org,tyoshino@chromium.org,yhirano@chromium.org
==========

to

==========
fetch: Drop Headers from HeadersInit typedef declaration.

This finally aligns our typedef with the version in the spec. We can do so
now that our bindings code can convert any iterable object into a sequence.

The Headers::FillWith(const Header*, ...) overload has been kept though, as
it is used by other classes that may need to fill a Headers object with
another existing one (when initializing a Request object, for example).

R=falken@chromium.org,mkwst@chromium.org,tyoshino@chromium.org,yhirano@chromi...
==========

[Raphael Kubo da Costa (rakuco), 2017-05-01 12:11:28]

raphael.kubo.da.costa@intel.com changed reviewers:
+ falken@chromium.org

[Raphael Kubo da Costa (rakuco), 2017-05-01 12:11:32]

The CQ bit was checked by raphael.kubo.da.costa@intel.com to run a CQ dry run

[commit-bot: I haz the power, 2017-05-01 12:11:38]

Dry run: CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Raphael Kubo da Costa (rakuco), 2017-05-01 12:16:58]

+falken for the change to service_worker_browsertest.cc

With |Headers| removed from the |HeadersInit| IDL typedef, something like
  var h = new Headers;
  h.set('Content-Language', 'fi');
  var response = new Response(..., { headers: h });

will cause |h| to be converted to a sequence<sequence<ByteString>> when the
Response's |header| member is filled with it. Since Header's iterator is used
when filling it and it uses the "sort and combine" steps from Fetch, all header
names will be lower-cased.

This is a behavior change, but since Fetch API users are supposed to use
Header's methods such as get() and has() which are byte-case-insensitive, I
don't expect any issues.

[Raphael Kubo da Costa (rakuco), 2017-05-01 12:53:02]

On 2017/05/01 12:16:58, Raphael Kubo da Costa (rakuco) wrote:
> +falken for the change to service_worker_browsertest.cc

Also note that this change basically makes the test look like what it used to
before https://codereview.chromium.org/2787003002

[commit-bot: I haz the power, 2017-05-01 13:58:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-05-01 13:58:04]

Dry run: This issue passed the CQ dry run.

[falken, 2017-05-02 03:43:32]

On 2017/05/01 12:53:02, Raphael Kubo da Costa (rakuco) wrote:
> On 2017/05/01 12:16:58, Raphael Kubo da Costa (rakuco) wrote:
> > +falken for the change to service_worker_browsertest.cc
> 
> Also note that this change basically makes the test look like what it used to
> before https://codereview.chromium.org/2787003002

service_worker_browsertest.cc lgtm

[falken, 2017-05-02 03:48:04]

On 2017/05/02 03:43:32, falken (away May 3-5) wrote:
> On 2017/05/01 12:53:02, Raphael Kubo da Costa (rakuco) wrote:
> > On 2017/05/01 12:16:58, Raphael Kubo da Costa (rakuco) wrote:
> > > +falken for the change to service_worker_browsertest.cc
> > 
> > Also note that this change basically makes the test look like what it used
to
> > before https://codereview.chromium.org/2787003002
> 
> service_worker_browsertest.cc lgtm

Is there a bug for this? BUG=687155, 705490?

[Raphael Kubo da Costa (rakuco), 2017-05-02 09:16:44]

On 2017/05/02 03:48:04, falken (away May 3-5) wrote:
> On 2017/05/02 03:43:32, falken (away May 3-5) wrote:
> > On 2017/05/01 12:53:02, Raphael Kubo da Costa (rakuco) wrote:
> > > On 2017/05/01 12:16:58, Raphael Kubo da Costa (rakuco) wrote:
> > > > +falken for the change to service_worker_browsertest.cc
> > > 
> > > Also note that this change basically makes the test look like what it used
> to
> > > before https://codereview.chromium.org/2787003002
> > 
> > service_worker_browsertest.cc lgtm
> 
> Is there a bug for this? BUG=687155, 705490?

This is not related to those bugs. This CL is about IDL conformance, which was
depending on changes to the bindings code that I've been landing over the last
few months. I don't think there's a specific bug for this IDL bit, but I can
create one if you prefer.

[yhirano, 2017-05-02 11:02:10]

On 2017/05/02 09:16:44, Raphael Kubo da Costa (rakuco) wrote:
> On 2017/05/02 03:48:04, falken (away May 3-5) wrote:
> > On 2017/05/02 03:43:32, falken (away May 3-5) wrote:
> > > On 2017/05/01 12:53:02, Raphael Kubo da Costa (rakuco) wrote:
> > > > On 2017/05/01 12:16:58, Raphael Kubo da Costa (rakuco) wrote:
> > > > > +falken for the change to service_worker_browsertest.cc
> > > > 
> > > > Also note that this change basically makes the test look like what it
used
> > to
> > > > before https://codereview.chromium.org/2787003002
> > > 
> > > service_worker_browsertest.cc lgtm
> > 
> > Is there a bug for this? BUG=687155, 705490?
> 
> This is not related to those bugs. This CL is about IDL conformance, which was
> depending on changes to the bindings code that I've been landing over the last
> few months. I don't think there's a specific bug for this IDL bit, but I can
> create one if you prefer.

I think 705490 is related, as this change fixes one fetch wpt, right?

[Raphael Kubo da Costa (rakuco), 2017-05-02 11:03:57]

Description was changed from

==========
fetch: Drop Headers from HeadersInit typedef declaration.

This finally aligns our typedef with the version in the spec. We can do so
now that our bindings code can convert any iterable object into a sequence.

The Headers::FillWith(const Header*, ...) overload has been kept though, as
it is used by other classes that may need to fill a Headers object with
another existing one (when initializing a Request object, for example).

R=falken@chromium.org,mkwst@chromium.org,tyoshino@chromium.org,yhirano@chromi...
==========

to

==========
fetch: Drop Headers from HeadersInit typedef declaration.

This finally aligns our typedef with the version in the spec. We can do so
now that our bindings code can convert any iterable object into a sequence.

The Headers::FillWith(const Header*, ...) overload has been kept though, as
it is used by other classes that may need to fill a Headers object with
another existing one (when initializing a Request object, for example).

BUG=705490
R=falken@chromium.org,mkwst@chromium.org,tyoshino@chromium.org,yhirano@chromi...
==========

[Raphael Kubo da Costa (rakuco), 2017-05-02 11:04:20]

On 2017/05/02 11:02:10, yhirano (away May 3 - May 5) wrote:
> I think 705490 is related, as this change fixes one fetch wpt, right?

Hmm, that's true. I've added a reference to it in the CL description.

[yhirano, 2017-05-02 11:05:59]

lgtm

[Raphael Kubo da Costa (rakuco), 2017-05-02 11:07:09]

The CQ bit was checked by raphael.kubo.da.costa@intel.com

[commit-bot: I haz the power, 2017-05-02 11:07:20]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-05-02 11:11:25]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1493723229263210,
"parent_rev": "ae5512e5d564f1a26e07c79bcc96bf2a27e68f5b", "commit_rev":
"37b22b3ee932500caa379e06b0a170cc164c8d03"}

[commit-bot: I haz the power, 2017-05-02 11:11:42]

Description was changed from

==========
fetch: Drop Headers from HeadersInit typedef declaration.

This finally aligns our typedef with the version in the spec. We can do so
now that our bindings code can convert any iterable object into a sequence.

The Headers::FillWith(const Header*, ...) overload has been kept though, as
it is used by other classes that may need to fill a Headers object with
another existing one (when initializing a Request object, for example).

BUG=705490
R=falken@chromium.org,mkwst@chromium.org,tyoshino@chromium.org,yhirano@chromi...
==========

to

==========
fetch: Drop Headers from HeadersInit typedef declaration.

This finally aligns our typedef with the version in the spec. We can do so
now that our bindings code can convert any iterable object into a sequence.

The Headers::FillWith(const Header*, ...) overload has been kept though, as
it is used by other classes that may need to fill a Headers object with
another existing one (when initializing a Request object, for example).

BUG=705490
R=falken@chromium.org,mkwst@chromium.org,tyoshino@chromium.org,yhirano@chromi...

Review-Url: https://codereview.chromium.org/2854613002
Cr-Commit-Position: refs/heads/master@{#468595}
Committed:
https://chromium.googlesource.com/chromium/src/+/37b22b3ee932500caa379e06b0a1...
==========

[commit-bot: I haz the power, 2017-05-02 11:11:44]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/37b22b3ee932500caa379e06b0a1...