Bug 164889 – Web Inspector: Show Preflight Request information in inspector

• Status: NEW
• Component: Web Inspector

[Joseph Pecoraro]

Summary:
Show Preflight Request information in inspector

Almost any request can have a preflight request. We should be able to show preflight request data in Web Inspector as it contributes to load times and failure conditions.

[Radar WebKit Bug Importer]

<rdar://problem/29319952>

[Joseph Pecoraro]

For more information about Preflight requests read up on CORS:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
https://www.w3.org/TR/cors/

All non-simple cross-origin requests do a preflight OPTIONS request to establish whether or not the request method / request headers will be allowed by the remote origin. (Origin, Access-Control-Request-Method, Access-Control-Request-Headers).

The response from the server may include useful information about what is allowed in the cross-origin request (Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Max-Age, Access-Control-Expose-Headers, Access-Control-Allow-Credentials).

For developers debugging CORS issues, knowing preflight requests and responses will be necessary to answer questions like:

  - Why was my CORS request denied?
  - Why was my header not sent?
  - Why did I get an error?
  - Were my credentials sent?

Further they should probably be associated with the resource request that was ultimately being preflighted instead of appearing as a separate resource. Each (origin, URL, useCredentials) tuple has its own preflight cache, so it would seem this is most commonly on a per-resource basis (each different URL resource would have its own preflight). So it would be most useful to only have your real resources in the sidebar and attached to that resource you could get the Preflight information.

We should certainly be showing Preflight Requests that result in failures. That is a real request that might reveal a server side issue that developer would encounter. For example a 501 Server-Side issue responding to OPTIONS preflight requests.


Brainstorming some UIs:

    - Network Datagrid could have a Preflight column with a [✔] if preflighted
    - Network DataGrid could have a CORS column with values like (No, Yes - Simple, Yes - Preflighted)

    - Network Datagrid could show both requests / responses on their own line
    - Network Datagrid could show a sequence / series of requests for an individual resource.
      The same visualizations can apply to redirects / streaming data. For example:

      Request basic:

          |-------------|###########)
             (request)    (response)

      Request with redirect:

          |-------------|#|------|#####)
                     (redirect)

      Preflighted request:

          |--------|*) |-------------|###########)
           (preflight)           (normal)

    - There should not be a Resource in the Resources sidebar. There is no resulting Resource.
    - For Preflight requests we may want to highlight the relevant headers when showing them.
      (Origin, Access-Control-*) perhaps even hiding browser headers by default (User-Agent).

However I think it should be clear that when viewing an individual resource, you should be able to see the Preflight information for that resource. Ideally it would be collapsed and immediately accessible, and worst case a link/goto to the preflight request to get the data.

[Przemyslaw Gorszkowski]

There is also some other request about the same feature: https://bugs.webkit.org/show_bug.cgi?id=213215. It seems to be quite desirable.

It there any pending patch which I could continue? Any advice about possible implementation(where to start, etc.) would be appreciated.

[Sam Sneddon [:gsnedders]]

*** Bug 213215 has been marked as a duplicate of this bug. ***

[Sam Sneddon [:gsnedders]]

*** Bug 206349 has been marked as a duplicate of this bug. ***