Bug 156255 - Refactor Windows/GTK/EFL usage of addHTTPHeaderField to send an HTTPHeaderName instead of a String
Summary: Refactor Windows/GTK/EFL usage of addHTTPHeaderField to send an HTTPHeaderNam...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKitGTK (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 155602
Blocks:
  Show dependency treegraph
 
Reported: 2016-04-05 15:24 PDT by John Wilander
Modified: 2016-04-05 15:27 PDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Wilander 2016-04-05 15:24:06 PDT
During the https://bugs.webkit.org/show_bug.cgi?id=155602 it was noted that Windows, GTK, and EFL call ResourceResponseBase::addHTTPHeaderField() with a String reference as the header name. We should refactor these pieces to instead use HTTPHeaderName::findHTTPHeaderName() and send a HTTPHeaderName enum value to esourceResponseBase::addHTTPHeaderField(). Thus, unknown header names can be handled where error handling makes more sense.

The same goes for ResourceRequestBase::addHTTPHeaderField().

After this refactoring it should be possible to remove the addHTTPHeaderField() functions that receive HTTP header names as strings.