Repair HTTP Range & Partial Response Bugs

I have analyzed the provided Go handler. The issue stems from an off-by-one error in the Content-Range header calculation and a missing check for the If-Range header, which causes the client to fail its consistency check during resume.

HTTP Range Repair Analysis

Proposed Patch (Go)

func handleRangeRequest(w http.ResponseWriter, r *http.Request, size int64, modTime time.Time, etag string) {
    rangeHeader := r.Header.Get("Range")
    if rangeHeader == "" {
        // Normal 200 OK flow
        return
    }

    // Fix: Verify If-Range validator for resumable consistency
    if ifRange := r.Header.Get("If-Range"); ifRange != "" {
        if ifRange != etag && ifRange != modTime.Format(http.TimeFormat) {
            // Validator mismatch: must return full entity
            serveFullContent(w, r)
            return
        }
    }

    ranges, err := parseRange(rangeHeader, size)
    if err != nil {
        w.Header().Set("Content-Range", fmt.Sprintf("bytes */%d", size))
        w.WriteHeader(http.StatusRequestedRangeNotSatisfiable)
        return
    }

    ra := ranges[0]
    w.Header().Set("Content-Range", ra.contentRange(size)) // Ensure inclusive: bytes start-end/total
    w.Header().Set("Accept-Ranges", "bytes")
    w.WriteHeader(http.StatusPartialContent)
    // ... write io.NewSectionReader
}

Next steps

1. Update the parseRange helper to return inclusive byte offsets.
2. Verify that your ETag generation is deterministic across server restarts.
3. Test with curl -H "Range: bytes=0-10" -H "If-Range: invalid-etag" to ensure it falls back to 200 OK.