Should I expect JPEG SOI marker at very beginning of the data stream?

Question

... or should I go deeper into the data stream looking for 0xFF 0xD8 sequence?

From this Q, I've learned what APPn does not have to follow SOI immediately. Are there specification compliant JPEG cases where SOI position != beginning of the stream?

---

A quote from the specification (Annex B, § 1.1.2):

Markers serve to identify the various structural parts of the compressed data formats. Most markers start marker segments containing a related group of parameters; some markers stand alone. All markers are assigned two-byte codes: an X’FF’ byte followed by a byte which is not equal to 0 or X’FF’ (see Table B.1). Any marker may optionally be preceded by any number of fill bytes, which are bytes assigned code X’FF’.

Answer 1

libjpeg does not allow garbage before the SOI:

/* Like next_marker, but used to obtain the initial SOI marker. */
/* For this marker, we do not allow preceding garbage or fill; otherwise,
* we might well scan an entire input file before realizing it ain't JPEG.
* If an application wants to process non-JFIF files, it must seek to the
* SOI before calling the JPEG library.
*/

From: Random libjpeg mirror.

E.g. the go implementation also does not allow preceding garbage.

However, if in doubt, stick to Postel's Law:

Be liberal in what you accept, and conservative in what you send

Although, you don't want to be too liberal, or you might end up extracting not the actual JPEG from the stream but the embedded EXIF thumbnail or something like that.