Testcafe-hammerhead: [RequestHook]: add methods for manipulation with response headers

[miherlosev]

https://devexpress.github.io/testcafe/documentation/test-api/intercepting-http-requests/creating-a-custom-http-request-hook.html#the-onresponse-method

ResponseEvent.setHeader(name, value)
ResponseEvent.removeHeader(name)

[NickCis]

Hi!, I was trying to implement this feature, but, before making changes (and get them rejected) i though that it would be better to discuss the implementation approach.

First of all, what is the ideal interface?:
a. Copy the onRequest interface, and directly set / modify headers of an object: ie: responseEvent.response.headers['some-header'] = 'some-value'
b. Implement specific methods:

• responseEvent.setHeader(name, value)
• responseEvent.removeHeader(name)

Regarding the request pipeline, the headers (and all the response) are sent before the onResponse event is dispatched ([1], [2]). So, am i correct saying that this order should be inverted? (ie: first dispatch the onResponse, then send headers and payload).

In addition, i suppose that the onResponse handler should be run after the headerTransforms.forResponse is executed, Is that supposition ok?

[1] [sendResponseHeaders](https://github.com/DevExpress/testcafe-hammerhead/blob/c7d62856efb23148b4b5f6a2b8bc9c7dafb52f12/src/request-pipeline/index.js#L109), onResponse
[2] [sendResponseHeader](https://github.com/DevExpress/testcafe-hammerhead/blob/c7d62856efb23148b4b5f6a2b8bc9c7dafb52f12/src/request-pipeline/index.js#L184), onResponse

[miherlosev]

Hi @NickCis

We planned this feature for internal purposes.
Before discussing the API interfaces, could you please tell us about you use case?

[NickCis]

Hi @miherlosev , thank you for the quick response.

The use case is interacting with an external payment api that is used by adding an iframe to the web. The idea is to set headers in order to allow interaction with the iframe.

[miherlosev]

Would you please clarify which headers you want to modify to allow interaction with the iframe?

[NickCis]

Yes, sorry for being too shynthetic.

This 3rd party API sets the X-Frame-Options header to ALLOW-FROM <our domain>. CI runs tests against a localhost domain, so the iframe cannot be used. The idea is to test a particular branch (devs usually use a browser plugin in order to modify headers).

Another use case, that addresses this feature, is implementing a workaround for Facebook login.

[miherlosev]

Thank you for the detailed explanation of your scenario. Before discussing a public API we need to perform an additional investigation.

[miherlosev]

Having discussed this with the team, we can suggest the following API:

• removeHeader(name)
• setHeader(name, value)

These methods will be defined as methods of the ConfigureResponseEvent class.

The feature implementation can be divided into 2 parts:

• split the header-transforms.js
  file into two parts:
  
  
  
  1. header-transforms.js - contains only transformations for request and response headers
  
  
  2. header-transform-api.js - contains the forRequest, forResponse and transformHeadersCaseToRaw methods
  
  

• change response headers transformation order.
  
  
  
  1. apply all header changes from request hooks
  
  
  2. apply header transformation
  
  
  3. write updated headers to the response.
  
  

[NickCis]

@miherlosev I'll be working on that on PR #1790

[NickCis]

The proposed implementation will allow to modify the headers in the onConfigureResponse event.

The problem with this event is that, in testcafe, is private. The onConfigureResponse event calls the _onConfigureResponse method of the RequestHook which has a default implementation and is somehow private.

In addition of this PR, won't testcafe need one to make this api public?, ei: add a onConfigureResponse method which has to be optionally implemented on request hooks (if we force users to implement this method, testcafe update will break people's code when they update) which will be called by the _onConfigureResponse method.

[miherlosev]

Yes, it's more appropriate to mark the onConfigureResponse event as public and remove the default implementation from the RequestHook base class.
We will do it only before the [email protected] was released, because it's a breaking change.
Now, let's keep this method as is.
So, the use of the setHeader and removeHeader methods will look like this:

class CustomRequestHook extends RequestHook {
    _onConfigureResponse (event) {
      super._onConfigureResponse(event);

     event.setHeader('x-frame-options', 'allow-from https://example.com/');
     event.removeHeader('x-header-name');
    }
}

[lock[bot]]

This thread has been automatically locked since it is closed and there has not been any recent activity. Please open a new issue for related bugs or feature requests. We recommend you ask TestCafe API, usage and configuration inquiries on StackOverflow.