webdriver_bidi_get_reponse_body.md

Proposal for response bodies for pre review

Response bodies configuration (new)

New struct for BiDi session

A BiDi session has a an optional response bodies configuration which is a
network.ResponseBodiesConfiguration. It is initially null.

network.ResponseBodiesConfiguration = (
  maxResponseSize: js-uint,
  urlPatterns: [*network.UrlPattern]
)

Response map (new)

New struct for BiDi session

network.ResponseBodyData = (
  request: network.Request, 
  navigable: browsingContext.BrowsingContext, 
  response: network.BytesValue / null, 
  isAvailable: bool
)

A BiDi session has a response map which is a map between
network.Request and network.ResponseBodyData.

Q: should we rather prefill the map on beforerequestsent and have state instead of isAvailable with "pending" "available" "unavailable" values?

browsingContext.navigationCommitted (update)

Update current event

Add to the session steps for browsingContext.navigationCommitted:

  If the context is a top level navigable

    For each response body in session response bodies map

      If response body navigable is navigable

        then set the response field of response body to null and the isAvailable
        field to false

browsingContext.contextDestroyed (update)

Add same steps as for navigationCommitted

network maybe add response to response map (new)

To maybe add response to response map given response

  If session response bodies configuration is not null:

    Let url patterns be intercept’s url patterns

      If url patterns is not empty:

        Let match be false

        For each url pattern in url patterns:

            If match URL pattern with url pattern and url:

                Set match to true.

                Break.

        If match is false, return.

    Let response body be a map matching the network.ResponseBodyData
    production with request set to response's request, navigable set to
    response's context, response set to null, and isAvailable set to false.

    If response content size is smaller than response bodies configuration
    maxResponseSize:

      Set response body response to a map matching the network.BytesValue
      production (...).

      Q: Should we have a different status for responses which are too big?

    Set response map[response's request] to response body.

network.responseCompleted

Before the emit step, call maybe add response to response map

network.enableResponseBodies

New command

network.EnableResponseBodies = (
  method: "network.enableResponseBodies",
  params: network.EnableResponseBodiesParameters
)

network.EnableResponseBodiesParameters = {
  configuration: network.ResponseBodiesConfiguration
}

Let configuration be command parameters["configuration"].

If session response bodies configuration is not null, raise unable to set
response bodies configuration.

Set session response bodies configuration to a map matching the
network.ResponseBodiesConfiguration production with maxResponseSize set to
configuration["maxResponseSize"] and urlPatterns set to
configuration["urlPatterns"].

network.disableResponseBodies

New command

network.DisableResponseBodies = (
  method: "network.disableResponseBodies",
  params: EmptyParams,
)

Set session response bodies configuration to null.

network.clearResponseBodiesCache

New command

network.ClearResponseBodiesCache = (
  method: "network.clearResponseBodiesCache",
  params: EmptyParams,
)

Set session response map to an empty map

network.getResponseBody

New command

network.GetResponseBody = (
  method: "network.getResponseBody",
  params: network.GetResponseBodyParameters
)

network.getResponseBodyParameters = {
  request: network.Request
}

browser.GetResponseBodyResult = {
  body: network.BytesValue,
}

Same as in the current PR.

Some side comments:

• clearing response bodies on any navigation + context destruction because it seems challenging for Chrome to guarantee responses will be available after document was disposed or navigation happened. Might be annoying for iframe scenarios.
• did not add restrictions on which response bodies are stored, should probably restrict to avoid workers
• did not add userContext/contexts parameters to enableResponseBodies, but we could
• should we add a total size ? in this case need to implement a fifo logic?
• should we add defaults in case users only want to enable response bodies?
• should we have a different error message for responses which were too big to be stored vs responses which were evicted because the document navigated