Client yang hanya memiliki sebagian dari sebuah representasi HTTP menghadapi masalah konsistensi ketika kemudian meminta byte yang belum diterima. Offset byte hanya bermakna terhadap representasi yang byte-nya menjadi dasar offset tersebut. Jika representasi terpilih berubah di antara request, menggabungkan prefix lama dengan suffix baru dapat menghasilkan data yang tidak pernah dikirim server mana pun.

If-Range mengikat identitas representasi pada boundary pengambilan parsial tersebut. Ketika validator-nya cocok, server dapat memproses field Range yang menyertainya. Ketika tidak cocok, server mengabaikan Range dan mengirim representasi terpilih secara lengkap melalui jalur response sukses biasa, alih-alih mengembalikan response failed-precondition.

Fallback inilah properti utamanya. If-Range bukan validator cache umum dan bukan write guard. Ia adalah sakelar kondisional antara transfer parsial dan transfer lengkap.

Offset byte hanya berlaku untuk satu representasi

Bayangkan client menerima 1.000 byte pertama dari representasi berukuran 10.000 byte sebelum koneksinya terputus. Response juga membawa strong entity tag:

HTTP/1.1 200 OK
ETag: "rev-8"
Content-Length: 10000

Client kemudian dapat meminta byte sisanya:

GET /archive.bin HTTP/1.1
Range: bytes=1000-
If-Range: "rev-8"

Jika "rev-8" masih cocok secara kuat dengan entity tag representasi terpilih, server dapat memproses range dan, bila kondisi range lainnya terpenuhi, mengembalikan partial content:

HTTP/1.1 206 Partial Content
ETag: "rev-8"
Content-Range: bytes 1000-9999/10000

Sekarang client memiliki potongan yang terikat pada validator yang sama. Offset range dan prefix yang tersimpan mengacu pada satu urutan data representasi.

Misalkan resource berubah menjadi "rev-9". Memproses bytes=1000- terhadap representasi baru itu dapat membuat prefix lama tidak aman untuk digabungkan dengan suffix yang dikembalikan. Offset numerik yang sama tidak mengatakan apa pun tentang kesinambungan semantik antara dua versi representasi.

If-Range membuat boundary versi tersebut eksplisit.

Kondisi yang gagal menghilangkan field Range

Perilaku saat kondisi gagal berbeda dari HTTP precondition biasa. Jika kondisi If-Match gagal pada request tempat precondition tersebut berlaku, hasil normalnya adalah 412 Precondition Failed. Kondisi If-Range yang false memiliki efek lain: recipient mengabaikan Range.

Secara konseptual, branch-nya adalah:

validator cocok
    -> proses Range
    -> response parsial dapat berupa 206

validator tidak cocok
    -> abaikan Range
    -> kirim representasi lengkap saat ini

Untuk range request yang dapat dipenuhi dan kondisinya cocok, server yang mendukung range unit tersebut seharusnya mengirim 206 Partial Content. Jika kondisi If-Range false, pemrosesan range hilang dari semantik request, sehingga response menjadi hasil yang akan dihasilkan GET tanpa Range, umumnya 200 OK dengan representasi lengkap saat ini.

Desain ini menghindari round trip tambahan. Client yang memakai If-Match bersama Range dapat mendeteksi representasi berubah melalui 412, tetapi setelah itu harus membuat request lain untuk representasi lengkap saat ini. If-Range langsung menyatakan recovery preference client: data parsial jika representasi lama masih berlaku, data lengkap jika tidak.

Strong validator melindungi proses penggabungan

Entity tag di If-Range tidak boleh weak. Client tidak boleh menghasilkan field seperti:

If-Range: W/"rev-8"

Pembatasan ini mengikuti operasi yang dilindungi. Menggabungkan byte range membutuhkan keyakinan bahwa data representasi berasal dari versi yang sama, bukan sekadar bahwa dua representasi dianggap ekuivalen menurut semantik cache validation yang lebih lemah.

Untuk bentuk entity tag, server mengevaluasi If-Range dengan strong comparison function. Karena itu weak tag tidak dapat menetapkan identitas yang diperlukan untuk melanjutkan range dengan aman.

Ini lebih ketat daripada use case yang hanya perlu menentukan apakah cached response masih dapat digunakan secara semantik. Weak validator dapat berguna ketika perubahan representasi tidak signifikan untuk cache validation, tetapi toleransi tersebut tidak kompatibel dengan menggabungkan urutan byte pada offset tetap.

Validator juga membutuhkan semantik server yang benar. Origin yang mengeluarkan strong entity tag yang sama untuk data representasi yang sudah berubah melanggar premis tempat range recombination bergantung. If-Range tidak dapat memperbaiki implementasi strong validator yang salah.

Date validator hanya sah pada kondisi yang sempit

If-Range dapat membawa HTTP date sebagai pengganti entity tag, tetapi bentuk date memiliki kondisi lebih ketat daripada sekadar menyalin nilai Last-Modified.

Client tidak boleh membuat If-Range berbentuk date ketika memiliki entity tag untuk representasi terkait. Client juga tidak boleh memakai date kecuali date tersebut memenuhi syarat sebagai strong validator menurut aturan validator HTTP.

Saat server mengevaluasi If-Range berbentuk date, kondisi hanya true jika date yang diberikan merupakan strong validator dan persis sama dengan nilai Last-Modified representasi terpilih. Jika tidak, kondisinya false dan Range diabaikan.

Aturan exact-match ini berbeda dari If-Unmodified-Since, yang perbandingannya didasarkan pada apakah representasi terpilih dimodifikasi setelah date yang diberikan. If-Range mengikat urutan byte parsial pada validator, sehingga exact validator match adalah relasi yang relevan.

Entity tag menghindari ketergantungan pada resolusi modification time dan karena itu menjadi bentuk yang lebih disukai ketika tersedia.

Content coding mengubah sistem koordinat byte

HTTP byte range mengacu pada octet data representasi setelah content coding diterapkan. Ia tidak mengacu pada decoded payload yang pada akhirnya mungkin digunakan aplikasi.

Jika sebuah representasi ditransfer dengan content coding, request seperti:

Range: bytes=5000-

mengacu pada offset byte 5.000 dalam encoded representation data. Server tidak dapat memperlakukannya sebagai offset 5.000 pada decoded source dan tetap mengklaim semantik HTTP byte-range biasa.

Detail ini memperkuat kebutuhan akan validator stabil pada resumed transfer. Perubahan content coding dapat mengubah urutan byte dan offset-nya meskipun informasi setelah decoding tampak ekuivalen. Strong validator yang dipakai untuk If-Range harus tetap konsisten dengan data representasi yang dipilih.

Content negotiation memperkenalkan boundary yang sama secara lebih luas. Request field dapat memengaruhi representasi mana yang dipilih. Resumed request yang menegosiasikan representasi berbeda tidak otomatis aman hanya karena target URI tetap sama. Validator matching adalah mekanisme protocol yang menentukan apakah data parsial yang tersimpan masih berasal dari representasi terpilih.

Dukungan Range tetap opsional

If-Range tidak memaksa server mengimplementasikan range request. Penanganan HTTP range bersifat opsional, dan server dapat mengabaikan Range pada kondisi yang diizinkan specification.

Dependensinya eksplisit: client tidak boleh menghasilkan If-Range tanpa Range, dan server harus mengabaikan If-Range ketika field Range tidak ada. Origin juga mengabaikan If-Range untuk target resource yang tidak mendukung range request.

Accept-Ranges: bytes dapat mengiklankan dukungan, tetapi sifatnya advisory, bukan janji bahwa setiap request berikutnya akan menerima partial content. Representasi dapat berubah, kondisi server dapat berubah, atau intermediary lain dapat ikut dalam pertukaran berikutnya.

Interpretasi protocol yang kuat karena itu memperlakukan 206 sebagai konfirmasi yang dapat diamati bahwa partial content benar-benar dikembalikan. Kehadiran Range, If-Range, atau field Accept-Ranges sebelumnya tidak dengan sendirinya membuktikan bahwa response body bersifat parsial.

Unsatisfiable range dievaluasi hanya pada branch yang cocok

Validitas dan satisfiability range menjadi relevan setelah conditional machinery mengizinkan pemrosesan range.

Jika validator If-Range cocok dan byte range yang diminta tidak dapat dipenuhi untuk representasi terpilih, server yang mendukung range seharusnya mengembalikan 416 Range Not Satisfiable. Untuk byte range, response tersebut seharusnya menyertakan nilai Content-Range yang membawa panjang lengkap saat ini jika diketahui:

HTTP/1.1 416 Range Not Satisfiable
Content-Range: bytes */10000

Namun jika If-Range false, server mengabaikan Range. Unsatisfiable range tidak lagi mengendalikan response karena request berjalan sebagai GET biasa terhadap representasi lengkap terpilih.

Urutan ini mencegah offset usang milik client lama mengubah pergantian versi menjadi range error. Response yang lebih berguna adalah representasi lengkap saat ini, yang menggantikan salinan parsial yang sudah stale.

Multiple range mempertahankan kebutuhan identitas yang sama

Field Range dapat meminta beberapa byte range. Successful multi-range response dapat memakai multipart/byteranges, dengan tiap body part membawa Content-Range sendiri.

If-Range berlaku terhadap range request secara keseluruhan. Ia tidak memvalidasi setiap interval yang diminta secara independen. Validator mengizinkan pemrosesan range set terhadap representasi terpilih, atau field range diabaikan.

Ini sesuai dengan data model: semua offset yang diminta mengacu pada satu representasi terpilih. Tidak ada protocol state yang masuk akal ketika sebagian offset berasal dari "rev-8" sementara yang lain diam-diam diambil dari "rev-9" lalu digabungkan sebagai satu resumed object.

Server tetap memiliki diskresi untuk menolak atau mengabaikan range set yang patologis, termasuk request dengan banyak range kecil atau tumpang tindih pada kondisi yang dijelaskan HTTP. Keberhasilan validator tidak menghapus batasan pemrosesan range tersebut.

Penyimpanan parsial membutuhkan metadata, bukan hanya byte

Client yang mengimplementasikan resumable retrieval membutuhkan lebih dari file fragment dan jumlah byte. Ia memerlukan metadata yang mengikat fragment pada representasi asalnya.

Setidaknya, state yang disimpan biasanya mencakup validator dan byte interval yang diwakili data lokal. Validator-lah yang membuat request If-Range berikutnya bermakna. Tanpanya, client tidak dapat meminta server membedakan kelanjutan representasi yang sama dari penggantian dengan versi yang lebih baru.

Boundary ini juga membatasi download-resume logic yang naif. Panjang file lokal 4 MiB tidak membuktikan bahwa Range: bytes=4194304- aman. Offset itu baru dapat digunakan kembali ketika client memiliki dasar yang kuat untuk mengaitkan byte lokal dengan representasi terpilih saat ini.

Protocol sengaja membuat dasar tersebut opaque. Strong entity tag dapat berupa revision token, nilai berbasis digest, atau identifier lain yang didefinisikan server. Client tidak perlu menafsirkannya; client hanya perlu menyimpan dan mengembalikannya persis sebagai validator.

If-Range menyatakan recovery preference

Conditional request sering mengekspos kondisi gagal sebagai response tersendiri. If-Range justru menyatakan preferensi transfer dengan dua hasil: lanjutkan dari data parsial yang tersimpan jika identitas representasi masih sama, atau ganti state parsial tersebut dengan representasi lengkap saat ini.

Perbedaan ini menjaga mekanismenya tetap sempit. Ia tidak menyediakan transaction isolation, tidak menjamin resumability, tidak mewajibkan dukungan range, dan tidak mendefinisikan persistence behavior untuk download manager. Ia hanya menghubungkan request Range dengan strong representation validator dan menetapkan apa yang terjadi ketika hubungan itu tidak lagi berlaku.

Konsekuensi yang dapat diamati sangat spesifik. Identitas yang cocok mempertahankan kemungkinan transfer parsial. Identitas yang berubah menghapus byte-range request dari pertimbangan, sehingga offset stale tidak diterapkan pada representasi yang berbeda.