You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When updating the major version of Jersey, I encountered an issue. Since strict validation of the filename* parameter in the Content-Disposition header was introduced in #4647 to comply with the required RFC, some previously working HTTP calls now produce errors.
For example, I have some external HTTP clients that (for reasons unknown to me) have similar values for both filename and filename*, where only the raw filename is saved (f.e. filename*=my-file.txt).
I believe I am not the only one facing this issue, and I think it would be useful to have an option - configured via environment variables or properties -that could temporarily disable strict filename* validation. This way, the filename and encoding could be populated with default values instead of throwing a ParseException.
I understand that such validation behavior is necessary, but allowing temporary flexibility could simplify the transition to the new version.
If you find this idea useful, please let me know, and I will prepare a PR.
The text was updated successfully, but these errors were encountered:
Hello, everyone!
When updating the major version of Jersey, I encountered an issue. Since strict validation of the
filename*
parameter in the Content-Disposition header was introduced in #4647 to comply with the required RFC, some previously working HTTP calls now produce errors.For example, I have some external HTTP clients that (for reasons unknown to me) have similar values for both filename and filename*, where only the raw filename is saved (f.e.
filename*=my-file.txt
).I believe I am not the only one facing this issue, and I think it would be useful to have an option - configured via environment variables or properties -that could temporarily disable strict
filename*
validation. This way, the filename and encoding could be populated with default values instead of throwing aParseException
.I understand that such validation behavior is necessary, but allowing temporary flexibility could simplify the transition to the new version.
If you find this idea useful, please let me know, and I will prepare a PR.
The text was updated successfully, but these errors were encountered: