Last-Modified — mahiyyəti, mexanizmi və dəyişiklik tarixi başlığının konfiqurasiyası

Last-Modified nədir?

Last-Modified — şərti sorğular (conditional requests) başlıqlar qrupuna daxil olan HTTP başlığıdır. Server onu GET və ya HEAD cavabına əlavə edərək tələb olunan resursun son dəyişdirilmə tarixini və vaxtını HTTP-date formatında göstərir: Last-Modified: Wed, 02 Jul 2025 14:30:00 GMT. Müştəri (brauzer, mobil tətbiq, proksi) bu tarixi keşlənmiş resursla birlikdə saxlayır. Təkrar sorğuda müştəri eyni tarixlə If-Modified-Since başlığını göndərir və server onu resursun cari dəyişiklik vaxtı ilə müqayisə edir.

Last-Modified ilə şərti sorğu protokolu RFC 7232-də müəyyən edilmişdir və bütün müasir HTTP serverləri tərəfindən dəstəklənir. Tarix formatı ciddi şəkildə tənzimlənir — yalnız GMT (Greenwich Mean Time) saat qurşağı göstərilmədən. Server tüç mümkün formatda tarix qaytara bilər: RFC 1123 (standart), RFC 850 (köhnəlmiş) və ya ANSI C asctime. Praktikada demək olar ki, bütün serverlər 29 simvol sabit uzunluğunda RFC 1123 formatından istifadə edir.

Last-Modified keşləmənin valideyasiya mexanizmləri kateqoriyasına aiddir: o, müştəriyə cavabı keşləməyin mümkün olub-olmadığını demir, əksinə, artıq keşlənmiş resursun aktual olub-olmadığını yoxlamaq üçün alət verir. Keşləmə siyasəti Cache-Control başlığı vasitƏsilə ayrıca müəyyən edilir. Akamai (2025) tədqiqatına görə, Last-Modified-in Cache-Control ilə birlikdə düzgün konfiqurasiyası statik məzmun üçün origin serverlərə yükü 70%-ə qədər azaldır.

Last-Modified nə vaxt meydana çıxdı

Last-Modified başlığı hələ HTTP/1.0-da (RFC 1945, 1996) müəyyən edilmişdir və vebdə keşləməni idarə etməyin ilk mexanizmlərindən biri olmuşdur. ETag HTTP/1.1-də meydana çıxana qədər şərti sorğuların yeganə yolu idi. Yaşına baxmayaraq, başlıq sadəliyi sayəsində aktual olaraq qalır — server məzmunun heşini hesablamalı deyil, sadəcə fayl sistemindən faylın timestamp-ini və ya verilənlər bazasından updated_at sahəsini oxumaq kifayətdir.

Last-Modified necə işləyir?

Tam dövriyyü üç mərhələni əhatə edir. İlk sorğuda server resursu Last-Modified başlığı və 200 OK HTTP statusu ilə qaytarır. Müştəri cavabı tarixlə birlikdə keşləyir. Təkrar sorğuda müştəri saxlanılan tarixlə If-Modified-Since başlığını göndərir. Server bu tarixi resursun cari dəyişiklik vaxtı ilə müqayisə edir. Resurs dəyişməyibsə — boş gövdƏlə 304 Not Modified qaytarılır. Dəyişmişsə — yeni məlumatlar və yeni Last-Modified ilə 200 OK qaytarılır.

// İlk sorğu — server resursu tarixlə qaytarır
HTTP/1.1 200 OK
Content-Type: application/json
Last-Modified: Wed, 02 Jul 2025 14:30:00 GMT

[{"id": 1, "name": "Alice"}]

// Təkrar sorğu — müştəri saxlanılan tarixi göndərir
GET /api/users HTTP/1.1
Host: example.com
If-Modified-Since: Wed, 02 Jul 2025 14:30:00 GMT

// Cavab — məlumatlar dəyişməyib
HTTP/1.1 304 Not Modified

Mobil tətbiqlər üçün Last-Modified məlumat sinxronizasiyası zamanı xüsusilə faydalıdır. Tətbiq son uğurlu yeniləmənin tarixini saxlayır və onu serverə If-Modified-Since-də göndərir. Daha çox məlumat varsa və ya dəyişmişsə — server tam dəsti qaytarır. Yoxsa — 304, və tətbiq yerli surətdən istifadə edir. OkHttp və URLSession bu mexanizmi daxili keşləmə sistemləri vasitƏ silə avtomatik dəstəkləyir.

Server tarixi necə müəyyən edir

Statik fayllar üçün Nginx və Apache tarixi fayl sisteminin atributlarından — mtime (dəyişiklik vaxtı) götürür. Dinamik məzmun üçün server kodu biznes məntiqinə əsasən Last-Modified-i açıq şəkildə təyin etməlidir: verilənlər bazasındakı updated_at sahəsi, Git-dəki son commit tarixi, artefaktın qurulma timestamp-i. Last-Modified açıq təyin edilməyibsə, server ümumiyyətlə başlığı qaytarmaya bilər və müştəri tarixə görə şərti sorğular yerinə yetirə bilməz.

Last-Modified vs ETag

Last-Modified və ETag oxşar tapşırığı yerinə yetirir — müştəriyə keşin aktual olub-olmadığını yoxlamağa imkan verir — lakin prinsipial fərqlərə malikdir. Last-Modified vaxt damğasından istifadə edir, ETag isə unikal versiya identifikatorundan. Hər yanaşmanın özünün daha səmərəli olduğu ssenariləri var və HTTP spesifikasiyasının tövsiyəsi hər iki başlığı birlikdə istifadə etməkdir.

Last-Modified-in əsas üstünlüyü sadəlikdir. Server məzmunun heşini hesablamalı deyil ki, bu da hər sorğuda CPU resurslarına qənaət edir. Yüksək yüklü layihələr üçün statik fayllar və ya aydın vaxt damğası olan məlumatlar ötürürkən Last-Modified optimal seçim olaraq qalır. ETag isə mütləq dəqiqlik verir — JSON cavabında bir hərfin dəyişməsi ETag-i dəyişdirəcək, lakin tarixi dəyişdirməyə bilər (fayl eyni versiya ilə üzərinə yazılıbsa).

Birgə istifadə

Spesifikasiya hər iki başlığın eyni vaxtda qaytarılmasını tövsiyə edir. Server 200 OK cavabına həm Last-Modified, həm də ETag daxil edir. Müştəri hər iki şərti başlığı — If-Modified-Since və If-None-Match göndərir. Server əvvəlcə ETag-i yoxlayır (üstünlük variantı), sonra Last-Modified-i. Heç olmasa biri dəyişiklik siqnalı verirsə — tam cavab qaytarılır. Bu, maksimal elastiklik təmin edir: ETag dəqiqlik, Last-Modified isə ETag dəstəkləməyən müştərilər üçün ehtiyat yoxlama təmin edir.

Serverdə Last-Modified konfiqurasiyası

Last-Modified konfiqurasiyası serverin növündən asılıdır. Nginx və Apache üçün statik fayllara Last-Modified mtime əsasında avtomatik təyin edilir. Dinamik tətbiqlər üçün başlıq server kodunda təyin edilməlidir. Məşhur platformalarda konfiqurasiyaya baxaq.

// Express.js — Last-Modified təyini
app.get("/api/users", async (req, res) => {
    const updatedAt = await getLastUpdate()
    const ifModifiedSince = req.get("If-Modified-Since")

    // If-Modified-Since yoxlanılması
    if (ifModifiedSince && new Date(ifModifiedSince)
        >= updatedAt) {
        return res.status(304).end()
    }

    const users = await getUsers()
    res.set("Last-Modified", updatedAt.toUTCString())
    res.json(users)
})

Express.js nümunəsində server məlumatların son yenilənmə tarixini bazadan alır, müştəridən If-Modified-Since-i yoxlayır və keş aktualdırsa 304 qaytarır. Məlumatlar dəyişmişsə — yeni Last-Modified təyin edir və tam cavab qaytarır. toUTCString() tarixi tələb olunan HTTP formatına çevirir. İstehsalat mühitində hər müraciətdə verilənlər bazasına sorğu yerinə yetirməmək üçün updatedAt məlumatının Redis-də keşlənməsini əlavə etməyə dəyər.

Nginx: Last-Modified konfiqurasiyası

Nginx statik fayllar üçün Last-Modified-i faylın son dəyişdirilmə vaxtına əsasən avtomatik təyin edir. Davranışı etag direktivi (ETag-i söndürmək) və ya ngx_http_headers_module modulu vasitəsilə dəyişdirmək və ya söndürmək olar. Backend-ə proksi sorğuları üçün Last-Modified dəyişmədən upstream cavabından ötürülür. Vacib: backend Last-Modified qaytarmırsa, Nginx onu dinamik cavablar üçün avtomatik əlavə etməyəcək.

Məhdudiyyətlər və tələlər

Last-Modified-in bir neçə məlum məhdudiyyəti var. Əsası saniyəyə qədər dəqiqlikdir. Resurs bir saniyə ərzində iki dəfə dəyişmişsə, müştəri yeni versiyanı qaçıra bilər. Praktikada bu nadir ssenaridir, lakin yüksək tezlikli yeniləmələr (kotirovka lentləri, söhbətlər) üçün ETag tövsiyə olunur. İkinci məhdudiyyət klasterləşdirmə problemidir: müxtəlif serverlərdə fayl kopyalama və ya yerləşdirmə səbəbindən fərqli mtime-ə malik ola bilər, bu da Last-Modified-in uyğunsuz olmasına səbəb olur.

Üçüncü məhdudiyyət — saniyəyə qədər dəqiqliklə If-Modified-Since-in işlənməsi serverin tez-tez sorgulanması zamanı artıq sorğulara səbəb ola bilər. Müştəri hər 500 ms-də bir If-Modified-Since göndərirsə, server hər dəfə 200 OK qaytarır, çünki tarix dəyişməyib, lakin resurs əslində artıq yenilənib. Həll yolu ETag ilə birləşdirmədir: ETag saniyə ərzindəki dəyişikliyi tutacaq, Last-Modified isə ehtiyat variant olaraq qalacaq.

Dördüncü problem — Last-Modified eyni tarixə malik eyni resursun müxtəlif versiyalarını fərqləndirmir. Fayl ehtiyat nüsxadan bərpa edilmişsə və onun mtime orijinal ilə üst-üstə düşürsə, müştəri məzmunun dəyişdiyini görməyəcək. ETag bu problemi həll edir: məzmun heşi vaxt damğasından asılı olmayaraq hər hansı məlumat dəyişikliyində qərəntili şəkildə dəyişəcək. Kritik məlumatlar üçün həmişə hər iki başlıqdan istifadə edin.

• Saniyəyə qədər dəqiqlik — bir saniyə ərzindəki dəyişiklikləri tutmur; yüksək tezlikli yeniləmələr üçün ETag istifadə edin
• Klasterləşdirmə — mtime müxtəlif serverlərdə fərqlənə bilər; NTP vasitəsilə sinxronizasiya edin və ya ETag istifadə edin
• Race condition — resurs If-Modified-Since göndərildikdən sonra, lakin serverdə yoxlanılmamışdansa əvvəl dəyişərsə
• Proksi səhv şərhi — bəzi proksilər keşləmə zamanı Last-Modified-i dəyişdirə bilər; HTTPS bu problemi həll edir