Perhaps allow format=SAM for requests on the reads endpoint

[jmarshall]

For reads, htsget historically allows only BAM and CRAM formats to be selected. I think this was originally for MVP purposes, as there was no sensible reason to ask for SAM when that meant you would be stupidly asking for a gargantuan uncompressed data file, so it was naturally omitted from consideration.

Now that we have class=header requests, it might be sensible to allow SAM — particularly for header requests. See e.g. igvteam/igv.js#1187 (comment) in which an htsget user was not unreasonably absent-mindedly expecting to have a plain text SAM header returned for a header request.

So options might be

• not change anything
• allow format=SAM for class=header reads requests only
• allow format=SAM for any reads endpoint requests (with the unstated opinion that this is only sensible for header requests; servers might prefer to return an error for format=SAM complete stream requests)

---

The expectation that the header request would return textual SAM headers might have been aided by the protocol specification talking about “SAM/CRAM/VCF headers”. This phrasing was used to emphasise that this is about “HTS data format headers” as opposed to e.g. HTTP headers. But perhaps it could be rephrased as “SAM/BAM/CRAM/VCF/BCF headers” or in some other way.