Open Bug 1914351 Opened 3 months ago Updated 1 month ago

Allow to clear and modify all headers in network.continueResponse

Categories

(Remote Protocol :: WebDriver BiDi, defect, P3)

defect
Points:
2

Tracking

(Not tracked)

People

(Reporter: jdescottes, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [webdriver:m14])

At the moment, there are 5 response headers which can't be modified: https://searchfox.org/mozilla-central/rev/527d691a542ccc0f333e36689bd665cb000360b2/netwerk/protocol/http/HttpBaseChannel.cpp#2083-2088

  • Content-Type
  • Content-Length
  • Content-Encoding
  • Trailer
  • Transfer-Encoding

So at the moment we do not remove those headers from the existing response headers, and we also can't override them. However given that continueResponse is not actually allowed to modify the response, this should not be too problematic for the time being.

Severity: -- → S3
Points: --- → 2
Priority: -- → P3
Whiteboard: [webdriver:m12]

Kershaw: hi! I initially asked about this on the Necko matrix channel. It would be nice to have an additional API to bypass the limitation for those headers, but I have 2 questions before adding such an API.

First do you suggest just another argument for setResponseHeader, or should it rather be a completely separated entry point.
And second question, should we actually be careful with which values we allow here? In particular if we set a Content-Length which doesn't match the actual response content, could it lead to crashes or other severe issues?

Thanks!

Flags: needinfo?(kershaw)
Whiteboard: [webdriver:m12] → [webdriver:m13]

(In reply to Julian Descottes [:jdescottes] from comment #1)

Kershaw: hi! I initially asked about this on the Necko matrix channel. It would be nice to have an additional API to bypass the limitation for those headers, but I have 2 questions before adding such an API.

First do you suggest just another argument for setResponseHeader, or should it rather be a completely separated entry point.

I think another separated entry entry point would be better, since we don't need to update the current code.

And second question, should we actually be careful with which values we allow here? In particular if we set a Content-Length which doesn't match the actual response content, could it lead to crashes or other severe issues?

I think this should be fine, since some websites can return Content-Length that doesn't match the actual size. I assume the consumers of necko should already implement some checks.

Thanks.

Flags: needinfo?(kershaw)
Whiteboard: [webdriver:m13] → [webdriver:m14]
You need to log in before you can comment on or make changes to this bug.