1587696 - [rdm] HTTP request headers profile

Status: NEW

(DevTools :: Netmonitor, enhancement, P3)

Description

[Karl Dubost💡 :karlcow]

RDM has made a lot of progress. Thanks to all of you who hacked, designed, coded, improved it. That is super useful.

Here a feature which could be useful in some circumstances.

Some websites react differently depending on your HTTP headers. The same way current RDM allows customization of DPR, Screen size, User Agent string, touch ability, It would be good to be able to specify an HTTP Request profile, that you could save along the browser you created. You could that way change Accept-Language, Accept headers, etc.

Firefox sends for example.

Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.5
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Cache-Control: max-age=0
Connection: keep-alive
If-None-Match: "195f202ab1af3988bf3f38d085667091;gzip"
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:71.0) Gecko/20100101 Firefox/71.0

And Chrome

Accept-Encoding:	gzip, deflate
Accept-Language:	fr-FR,fr;q=0.9,en-US;q=0.8,en;q=0.7
Accept:	text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Cache-Control:	max-age=0
Connection:	keep-alive
If-None-Match:	"7276f1701e240da836da1454c9103149;gzip"
Upgrade-Insecure-Requests:	1
User-Agent:	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3937.0 Safari/537.36

And Safari

Accept-Encoding:	gzip, deflate
Accept-Language:	fr-fr
Accept:	text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Connection:	keep-alive
Upgrade-Insecure-Requests:	1
User-Agent:	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1 Safari/605.1.15

Comment 1

[Patrick Brosset <:pbro>]

Thanks for filing Karl. Great idea. Moving to the netmonitor to spark some conversations with Honza about this. This is probably not only limited to simulated devices in RDM.

Comment 2

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Thanks for the report Karl!

Agree, this would be super useful.

There are already similar reports:

• Bug 984122 - Option to set persistent custom headers for all requests.
• Bug 1273503 - Show original HTTP headers for requests

There are also some existing Chrome extensions

• https://chrome.google.com/webstore/detail/modify-headers-for-google/innpjfdalfhpcoinfnehdnbkglpmogdi
• https://chrome.google.com/webstore/detail/modheader/idgpnmonknjnojddfkpgkljpfnnfcklj?hl=en

Some general comments related to the UI/UX:

• The user should be able to create a list of custom headers. This could be done in a new side panel (e.g. similar to the Edit & Resend) or directly within the Headers panel
• Every item in the list of custom headers could have the following fields:
  • Header name
  • Header value
  • Header type (Response/Request/Upload)
  • Action (add, modify, remove)
  • Active (enabled/disabled)
• The user should be able to disable/enable the entire feature
• The user should be able to import/export the list (e.g. in JSON format)
• The list of custom headers would apply (if enabled) to every request/response executed on the page

@Harald WDYT?

Honza

Comment 3

[:Harald Kirschner :digitarald]

The feature would be very useful for a lot of testing, API design and security.

I'd imagine that header overrides could be integrated with Request Blocking; where a directive with filter can be switched between "Blocking", "Add/Remove/Modify Header", "Override Response", "Override Request".

An extension of this is an Intercept-Edit-Send use case, where matched requests are intercepted and trigger a dialog similar to edit-resend for in-flight edits.