I do not recommend the gin framework to add concurrency safety for headers.

It should be up to the user to decide whether to add locks. The main reasons are:

• This would increase the complexity of gin;
• From the perspective of http.Request, there is no control over adding locks;
• Combined with what is submitted in the current PR, the role of gin's mu is too multifaceted, and any operation could lead to a decrease in gin's performance;
• In some performance-sensitive scenarios, adding locks would limit the application's capabilities.

@flc1125 Since concurrent read writes to the headers map will lead to application crash, I believe this protection should be present in the library itself.

Combined with what is submitted in the current PR, the role of gin's mu is too multifaceted, and any operation could lead to a decrease in gin's performance;

Yes, this could be an issue so have created a separate mutex for header map

A similar change has been made to get and set context: #700

@saksham-arya-z

Thank you very much for accepting the feedback I provided.

However, I still insist that gin does not need to address the header competition issue.

For this, I sincerely apologize.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.99%. Comparing base (3dc1cd6) to head (cd86308).
Report is 83 commits behind head on master.

@@            Coverage Diff             @@
##           master    #4101      +/-   ##
==========================================
- Coverage   99.21%   98.99%   -0.22%     
==========================================
  Files          42       44       +2     
  Lines        3182     3397     +215     
==========================================
+ Hits         3157     3363     +206     
- Misses         17       24       +7     
- Partials        8       10       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.