[Webkit-unassigned] [Bug 164889] Web Inspector: Show Preflight Request information in inspector

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Dec 12 16:56:07 PST 2016


https://bugs.webkit.org/show_bug.cgi?id=164889

--- Comment #2 from Joseph Pecoraro <joepeck at webkit.org> ---
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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20161213/ff0676c9/attachment-0001.html>


More information about the webkit-unassigned mailing list