-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Base64 JsonMappingException: Unexpected end-of-input #2183
Comments
After further investigation it turns out jackson fails because it expects padding of the Base64 encoded data.
Output:
In contrast to the JRE the trailing |
The current solution / workaround is to use a custom serializer using annotations: |
Actually this may be a question of proper error messaging. Jackson default Base64 variant is Now: as to differences; as you probably know, Base64 encoding is rather loosely/ill-defined, f.ex: https://en.wikipedia.org/wiki/Base64 including whether padding is required or not. There are valid opinions for either way: requiring may be safer against invalid encoding or truncated data; but on the other hand it is theoretically optional if length of encoded String is known. In your case, since you prefer not requiring padding, you probably want to change the default |
Thanks for the swift response 👍 My main issue is the misleading wording of the error message and that none of the existing Base64Variants supports non-padding Base64. |
I think we are in agreement here! I actually thought one of the variants already allowed that, but apparently not. And although it is possible to create variant, that is not obvious thing to do and is just something that'd be better to avoid. So: I hope to resolve this when I get more time to work again on Jackson. Or if anyone with an itch could help, would be happy to get PR merged and such too. |
Hmmmh. Very interesting. I have been working a bit on improving error message, but now found out that part of the problem is that exception seen is actually side-effect of error handler that tries to get JSON String value, but that parser itself is in inconsistent state due to failure in base64 codec. |
You are one of the most responsive persons! Thanks a lot for caring! |
@ViToni you are welcome. I find that having "good users", ones who also care, helps a lot. And discussions that go depth like here, to find good workable solutions. One remaining thing: I looked at Wikipedia page, and while there are many variants, did not see obvious name for new one to add. Now, of existing variants, So I was wondering if you had something in mind; I could easily add new variant for 2.10, for convenience. If not that's fine too, but I don't want to forget one aspect that could further help usage. |
@cowtowncoder You might want to take a look at the Enoder class fom the JDK. For the decoder part I would go for a lenient default (which can read both: padded / non-padded) with an option to make it strict (but that's just me) if one wants to pin its "other" side to a certain expected format. Strict might refere to one of both modes:
But this might be over the top. |
I think the main challenge currently is just that there are named existing variants, applied to both, and I think attempting to change style of API could only be done for 3.x. Adding new methods in
of which all but last add and require padding; last one neither adds nor requires. I could add, say, Now... I guess the main remaining challenge here is that there does not exist option of "may but need not" use padding. I'll create a new issue for that work: it would go in 2.10. |
Created follow-up issue in |
My prod environment uses version 2.7.4. but I also tested that the bug occurs with the latest version from maven 2.9.7.
My test case include different serializer /deserializer. To ensure compatibility I have some fuzzy which created random data pass it to one serializer and the result to another deserializer. The output is expected to be the same as the original input. One test however which creates a random byte array fails sporadically with jackson.
Here is a minimal test case (the "short" JSON was specifically chosen because the original error message said some about '/'. after simplifying the data structure the error message changed)
To reproduce it easily the other Base64 decoder is from the JRE 8:
Expected out would be:
but is
The text was updated successfully, but these errors were encountered: