Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork158
[DRAFT] fix(core): support multiple base64 RFCs in Artifact serialization#1870
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:main
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
greghopkins commentedAug 23, 2023
@jan-molak The main issue with what's proposed here is this assertion: photo.map(value=>expect(value.toString('base64')).to.equal(photo.base64EncodedValue));
|
jan-molak commentedAug 23, 2023
Hello@greghopkins! Nice catch. Hmm, I think I'd be leaning more towards sanitising the input rather than relaxing the constraint. This would require us to change:
To avoid code duplication we could introduce a protected method in the base What do you think? |
Uh oh!
There was an error while loading.Please reload this page.
BrowserStack is returning some screenshot data in
base64with the older RFC 2045 style (see thevariants summary table), which includes mandatory newlines every 76 characters.More generally, in this style, whitespace (including newline) is ignored/irrelevant:
@jan-molak I'm not quite sure the best way to suggest to handle this... I see some options:
looksLikeBase64Encoded()which is what I started to do in this PRThoughts?