Improve error messaging for invalid headers
See original GitHub issueLibrary or service name Azure.Storage.Blobs
Description
When an InvalidHeaderValue
exception is thrown, information as to the header and its invalid value could be included in the exception (apparently it was, in past versions of the SDK). This would assist developers with troubleshooting and would make situations like this less likely to occur.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:9 (5 by maintainers)
Top Results From Across the Web
Providing a custom error message when HTTP header is ...
Providing a custom error message when HTTP header is invalid (contains whitespace) · java · spring-boot.
Read more >FIX: Invalid message error if the header field is longer than ...
Fixes an issue that triggers an invalid message error if a message in BizTalk Server has a header field that's more than 1000...
Read more >Additional Response Header Error Messages
The table below provides information about these responses/error messages, ... The submission contains empty or invalid credentials ( user and password ).
Read more >How To Fix HTTP Error 431 Request Header Fields Too ...
Learn how to fix the HTTP Error 431 Request Header Fields Too Large message using four simple troubleshooting tips.
Read more >Data Import error message reference - Analytics Help
Message Meaning So...
Empty column header at column number X. The upload file is missing a column header. Ed...
Multiple errors occurred: List of multiple...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Here’s the response:
Can’t the header name and value be parsed from that?
We do parse those into
RequestFailedException.AdditionalInformation
today.I thought that was displayed by default? If it’s not, we should fix that. If it’s not discoverable enough, we should consider post facto client-side validation to make it clearer.