←back to thread

669 points danso | 9 comments | | HN request time: 0.624s | source | bottom
Show context
crazygringo ◴[] No.23260987[source]
I thought iOS was supposed to convert HEIC images to JPEG automatically behind-the-scenes in any file transfer situation where HEIC isn't supported. The article itself even says:

> iPhones convert HEICs to JPEGs automatically when they’re attached to emails in the Mail app

I'm just curious technically why the same didn't happen with the testing portal? If you have a webpage that accepts image uploads, is iOS Safari not smart enough to do the same conversion?

Or was the portal programmed badly or in a non-standard way that that couldn't happen? Or is there a way to do it that the developers ignored?

Just curious for the technical details of who's more to blame here -- Apple not providing enough backwards compatibility, or the testing portal being designed poorly.

Because blaming students for not following obscure instructions to change their phone's overall configuration is not the right path. A national testing portal ought to support the default image format taken by the world's most popular phone, period.

replies(10): >>23261070 #>>23261216 #>>23261225 #>>23261243 #>>23261256 #>>23261511 #>>23261741 #>>23262179 #>>23262549 #>>23264304 #
1. danso ◴[] No.23261511[source]
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.

replies(4): >>23261655 #>>23264606 #>>23265511 #>>23267743 #
2. fortran77 ◴[] No.23261655[source]
Does the HTTP "accept" tag play a role here?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Ac...

replies(2): >>23261814 #>>23261861 #
3. Aqua_Geek ◴[] No.23261814[source]
I don't follow. How does the "Accept" header factor in here?
replies(1): >>23262050 #
4. detaro ◴[] No.23261861[source]
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.
5. tobylane ◴[] No.23262050{3}[source]
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.
6. derefr ◴[] No.23264606[source]
> 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.)

replies(1): >>23265875 #
7. hinkley ◴[] No.23265511[source]
So they did have a dress rehearsal, it just wasn't high fidelity, and on perhaps the most critical part of the process.
8. danso ◴[] No.23265875[source]
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)

9. MayorMonty ◴[] No.23267743[source]
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