Non-destructive request header access #467
-
I encountered an issue when reordering a handler's extractors that caused form submission data to cease posting as expected. The offending extractor was HeaderMap and moving it to the end of the extractors solves the problem as the docs advise. I dislike having bugs emerge due to argument order changes and am seeking a permanent solution. What options are available for accessing request header data without consuming it and causing other extractors to fail? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 10 replies
-
The design of extractors doesn't allow for this unfortunately. Extractors that consume the request body have the same problems, such as I recommend you write own |
Beta Was this translation helpful? Give feedback.
The design of extractors doesn't allow for this unfortunately. Extractors that consume the request body have the same problems, such as
String
,Bytes
, andJson
. So even if we madeHeaderMap
clone all the headers (which I don't think we should) body extractors would still have the issue.I recommend you write own
HeaderMapClone
extractor that clones the headers and leaves the original ones in place for other extractors.