Would it be correct for iOS Safari to quietly reencode to jpeg when a HEIC file is uploaded via a webform? How would Safari know that the site's backend didn't want an HEIC file?
I agree the HEIC thing is very confusing (having set up my parents' phones recently), but I can't see how Apple is to blame. For starters, the College Board could've done a much better job emphasizing this step for iOS users in its instructions page. But for me, the overriding factor that places blame squarely on the College Board is this from the article:
> Senior Dave Spencer took a demo test before his Calculus AB exam to make sure he understood the process for uploading photos. He Airdropped an iPhone image of his responses to his Mac and tried to convert it by renaming the HEIC file to PNG. Changing a file’s extension does not guarantee that it will be converted, but Spencer was still able to submit the demo test with no problem.
> Spencer used the same process on the real exam and thought it went through, but he received an email the next day saying the files were corrupted and that he needed to retake the test.
So it seems that students had access to a demo before test day. If I'm reading the story right:
- During the demo, Dave's phone produced a HEIC file
- The demo upload initially failed. So Dave renamed the file extension to PNG.
- Dave uploaded the PNG (in name only), and the demo did not return an error.
- Dave assumed, quite understandably, that the renaming trick would work on test day too.
So the onus in the College Board here: they provided a demo in which the photo upload function appears to have been stubbed (e.g. "if 'PNG|JPG|JPEG' is filename, print "Success"), giving students and teachers false assurance that photo uploads would work on test day.
> they provided a demo in which the photo upload function appears to have been stubbed (e.g. "if 'PNG|JPG|JPEG' is filename, print "Success"), giving students and teachers false assurance that photo uploads would work on test day.
I don't think it was exactly that it was stubbed out, per se; I would guess it was that the whole "backend" process involved either a human or an async batch process opening the file; and so in both the demo and prod environments, the upload of a file can succeed while the parsing of said file can fail (much later on, after the test is completed, during the grading phase.)
Yeah, I agree with you that the production app likely had an async process, i.e. queuing submissions and processing them first-come-first-serve, which would help explain why Dave didn't get the failure email until well into the next day. Seems safe to assume there was no process for (good) input validation upon upload.
And now that I reread the passage about Dave, I realize it's not necessarily true that Dave tried to upload HEIC, then got an error message, which led him to then rename the file. But he may have actually read the instructions about PNG/JPG being required, then thought he could just rename his file, then uploaded it as his first and only upload to the demo app. And whether the demo app actually did the upload, it apparently didn't do the parsing (I still think that was stubbed out; I can imagine an engineer thinking it'd save a headache if they disabled the parsing module for the demo server)
Yes there was a demo, but it didn't actually submit anything at all. It just mocked through what the exam would look like with timers.
The demo is still up and you can still look at it
So they did have a dress rehearsal, it just wasn't high fidelity, and on perhaps the most critical part of the process.
Does the HTTP "accept" tag play a role here?
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...
I don't follow. How does the "Accept" header factor in here?
Rule of least astonishment would be that the file is converted unless the accept header lists the heif file. At least by the expectations Apple set up, which don’t match up with standards.
That's a header the client sends to a server to indicate which formats it would like in the response to it's requests, and not relevant to the problem.