Incorrect response headers set by DownloadController/StreamController (violates RFC specs)

[randomnicode]

Likely might be true for other controllers too, just haven't gotten to it yet.

• Range request Content-Range response headers are not correctly set for partial responses and are non-compliant with RFC 7233. This effectively makes partial requests or resumable downloading useless.
• Not all Range request types are honored (but that's okay, it's allowed by spec), for instance no suffix byte or overlapping ranges currently work.
• Content-Range must be set for 206 responses, and yet is not.
• ETags are set only in certain conditions and have issues. Currently uses the MediaFile id as the ETag when that's no guarantee for the resource not changing (for instance, underlying file changes, id remains the same, the cache should be invalidated, but doesn't).
• Mediatypes are incorrectly set (IANA registry has nothing called "x-download")

A solution is proposed here at the airsonic-advanced fork (along with other optimizations and streamlining): https://github.com/airsonic-advanced/airsonic-advanced/pull/52

In lieu of, you could also probably get away with just adding and fixing the Content-Range response headers (just add a "/*" at the end for unknown lengths), switching the ETags to use a different representation (like file size), and fixing the media types to something coherent

[randomnicode]

Going to update the same topic after my review of StreamController, which again violates RFC 7233:

• 206 Partial Content has no meaning outside of a Range request header (in fact it is defined only in relation to the Range header in the spec itself):

  The 206 (Partial Content) status code indicates that the server is
  successfully fulfilling a range request for the target resource by
  transferring one or more parts of the selected representation that
  correspond to the satisfiable ranges found in the request's Range
  header field (Section 3.1).

• Yet Airsonic responds with a 206 even if Range header is not set by the client, which is in violation of the spec. The client has no reasonable expectation to receive a 206 if it didn't send a Range header. Specifically, if offsetSeconds parameter is set, a Range seems to be artificially added to the request: https://github.com/airsonic/airsonic/blob/master/airsonic-main/src/main/java/org/airsonic/player/controller/StreamController.java#L347-L350

This should be instead returning a full 200 OK response. Byte offsets shouldn't be treated in the same way as second offsets, particularly as a parameter field. The Ranges header is meant to be extensible for units other than bytes (needs to be registered at IANA), but it needs to come from the client. In either scenario, returning 206 Partial Content when client doesn't send Ranges is not legal.

• ETags again have the same problem as before. An id for the ETag means that even if the file changes, so long as the id remains the same, the file will not get invalidated.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.