ErrorBase
Independent technical referenceOfficial site
  • Software and digital services
  • HTTP service

304

HTTP 304 Not Modified: conditional GET cache validation

Verified with sources2 sourcesReviewed Oct 19, 2026
Technician coming? See the 2 steps they must show you

Risk level

Low

Usually safe to check without specialist tools.

Urgency

Medium

Quick answer

HTTP 304 (Not Modified) means the server received a conditional GET or HEAD request and confirmed your cached representation is still current. Check the If-None-Match or If-Modified-Since request headers and verify the client reuses its local cache instead of expecting a body.

Safety first

Stop and check this first

  • Never write a response body or trailers into an HTTP 304 message; RFC 9110 Section 15.4.5 specifies that a 304 response is terminated by the end of the header section and extra bytes can corrupt persistent connection framing.
  • Do not disable caching or strip ETag, Cache-Control, and Vary headers across an entire site before checking which client sent the conditional GET request.

Safe checks you can perform

  • Inspect the conditional request headers (If-None-Match and If-Modified-Since) and 304 validators
  • Verify that the 304 response includes required metadata headers and has no message body
  • Check how the client or shared proxy reuses its stored representation upon receiving 304

Leave these tasks to a qualified professional

  • Do not attempt this professional task: Fix server or CDN validator calculation and mandatory 304 header fields
  • Do not attempt this professional task: Configure the HTTP client to serve cached content on 304 or omit conditional headers when uncached

What a technician must be able to justify

Technician visit

These are the steps they must carry out and show you. Tick them as they work: if steps are skipped, do not accept a part swap.

These are not instructions for opening or handling the equipment yourself. They are the checks that should support a technical conclusion.

  1. Fix server or CDN validator calculation and mandatory 304 header fields

    What they doHave the backend developer or CDN engineer ensure ETag and Last-Modified change whenever the representation changes and that every 304 response generates Content-Location, Date, ETag, Vary, Cache-Control, and Expires matching a 200 (OK) response with zero body bytes.

    They must show youa paired curl trace of a 200 response and a conditional 304 response demonstrating identical ETag/Cache-Control/Vary headers and an updated ETag after a content deploy.

    In writingthe ETag generation rule and cache header configuration deployed on the origin or CDN.

  2. Configure the HTTP client to serve cached content on 304 or omit conditional headers when uncached

    What they doHave the client developer update the HTTP layer so 304 responses resolve with the locally stored representation, or stop injecting manual If-None-Match and If-Modified-Since headers when the client does not maintain a local cache.

    They must show youan integration test showing the client either resolving 304 from local cache or receiving a full 200 OK when no cached copy exists.

    In writingthe commit or configuration change in the client HTTP interceptor and the cache revalidation policy.

Before accepting a part or repair

Nothing has been shown yet. Do not accept a part swap based on the code alone.

Follow these steps

Note: Follow the documented order. An error code identifies the affected system, but it does not prove by itself which part has failed.

  1. Inspect the conditional request headers (If-None-Match and If-Modified-Since) and 304 validators

    Tools required

    Who:
    Your web developer or systems administrator inspecting the HTTP request and response headers.
    How:
    Examine the GET or HEAD request that received 304 for If-None-Match or If-Modified-Since, and compare those validator values with the current ETag and Last-Modified of the origin resource.
    Result that matters:
    You determine whether the request was a valid conditional cache revalidation against an unchanged resource.
    If the request carried an If-None-Match or If-Modified-Since value that matches the current representation on the server, that confirms HTTP 304 is the expected bandwidth-saving revalidation defined in RFC 9110 Section 15.4.5.
    If the underlying resource content changed on the origin yet the server still returned 304 for the old validator, that points to faulty ETag or Last-Modified generation on the server or CDN.
    Evidence to keep:
    Save the conditional request header lines and the matching 304 response header section.

    Never strip authentication headers or security controls globally just to force 200 responses; inspect the ETag and Cache-Control headers first.

    Evidence: IANA Hypertext Transfer Protocol Status Code Registry · RFC 9110 - HTTP Semantics · RFC 9110 section 15.4.5 - 304 Not Modified

  2. Verify that the 304 response includes required metadata headers and has no message body

    Tools required

    Who:
    Your backend developer testing the endpoint with curl or an HTTP client.
    How:
    Send one unconditional GET to record the 200 (OK) headers, then send a conditional GET with the returned ETag in If-None-Match and verify that the 304 response contains Content-Location, Date, ETag, Vary, Cache-Control, and Expires as applicable and ends with no body.
    Result that matters:
    RFC 9110 Section 15.4.5 mandates those six header fields when they would appear on a 200 response and states that a 304 response cannot contain content or trailers.
    If the 304 response omits ETag, Vary, or Cache-Control that were present on the 200 response or appends body bytes after the headers, that confirms a protocol compliance bug in the server or proxy.
    If all required headers match the 200 response and the message terminates cleanly at the end of the header section, that rules out a malformed 304 from the server.
    Evidence to keep:
    Keep the side-by-side header dump of the 200 (OK) response and the 304 (Not Modified) response.

    Perform verification requests using read-only GET or HEAD methods only.

    Evidence: RFC 9110 section 15.4.5 - 304 Not Modified

  3. Check how the client or shared proxy reuses its stored representation upon receiving 304

    No special tools

    Who:
    Your frontend or mobile developer reviewing the HTTP client cache layer.
    How:
    Verify whether the conditional GET originated from a browser/shared proxy cache or from custom application code, and check whether the client loads its stored body when 304 is returned.
    Result that matters:
    RFC 9110 Section 15.4.5 states that if a conditional request originated with an outbound client through a shared proxy, the proxy should forward the 304 response so the client uses its stored representation.
    If custom client code forwards or attaches If-None-Match without holding a cached representation to fall back on, that confirms the client is misusing conditional requests.
    If the browser or HTTP client loads the cached representation seamlessly on 304, that rules out any application defect.
    Evidence to keep:
    Record the client HTTP configuration or interceptor code where 304 responses and conditional headers are handled.

    Evidence: RFC 9110 section 15.4.5 - 304 Not Modified

Still not solved

If the error persists, stop here. See what the technician must do and show you.

Where this code applies

A code is meaningful only inside the right product and version context.

Primary scope

System
Software and digital services
Brand
HTTP
Product type
HTTP service

Known code variants

  • 304 Nicht geändert
  • 304 No modificado
  • 304 Non modificato
  • 304 Non modifié
  • 304 Not Modified
  • événement Fronius 304
  • evento Fronius 304
  • Fronius Ereignis 304
  • Fronius event 304
  • Fronius inverter 304
  • Fronius Symo / Eco 304
  • Fronius Wechselrichter 304
  • HTTP 304
  • HTTP status 304
  • inversor Fronius 304
  • inverter Fronius 304
  • onduleur Fronius 304

What it means

Defined in RFC 9110 Section 15.4.5 and registered by IANA in the 3xx Redirection class, HTTP 304 (Not Modified) indicates that a conditional GET or HEAD request would have resulted in a 200 (OK) response except that the precondition evaluated to false. The server redirects the client to reuse its stored representation as if it were the content of a 200 response. A 304 response must include Content-Location, Date, ETag, Vary, Cache-Control, and Expires if they would be sent in a 200 response, and terminates at the end of the header section with no content or trailers. Status 304 alone never indicates a server failure.

Warnings and stop conditions

  • Mediumsource verified

    Never write a response body or trailers into an HTTP 304 message; RFC 9110 Section 15.4.5 specifies that a 304 response is terminated by the end of the header section and extra bytes can corrupt persistent connection framing.

    Evidence: RFC 9110 section 15.4.5 - 304 Not Modified

  • Lowsource verified

    Do not disable caching or strip ETag, Cache-Control, and Vary headers across an entire site before checking which client sent the conditional GET request.

    Evidence: RFC 9110 section 15.4.5 - 304 Not Modified

Symptoms and causes

Probable causes · in order

  • Conditional GET or HEAD precondition evaluated to false because the cached copy is still validConfirmed

    Under RFC 9110 Section 15.4.5 and Section 13.1, when a client sends If-None-Match or If-Modified-Since and the target representation has not changed, the server returns 304 so no duplicate payload is transferred.

    Evidence: IANA Hypertext Transfer Protocol Status Code Registry · RFC 9110 - HTTP Semantics · RFC 9110 section 15.4.5 - 304 Not Modified

  • Custom HTTP client or API script treating 3xx status 304 as an error or empty body failureCommon

    Because a 304 response is terminated at the end of the header section and cannot contain content or trailers, an application that sends conditional headers without a local cache or rejects non-2xx statuses fails when 304 arrives.

    Evidence: RFC 9110 section 15.4.5 - 304 Not Modified

  • Origin server or CDN returning stale validators or omitting required 304 header fieldsPossible

    RFC 9110 Section 15.4.5 requires the server generating a 304 response to send any Content-Location, Date, ETag, Vary, Cache-Control, and Expires fields that would have been sent in a 200 (OK) response to the same request.

    Evidence: RFC 9110 section 15.4.5 - 304 Not Modified

Virtual technician

Does 304 still appear after these checks?

Answer a few questions to narrow down the likely cause and the safest next action. Guidance only - it never replaces a professional.

Start diagnosis

Sources and technical references

  1. 1

    IANA HTTP Status Code Registry

    Internet Assigned Numbers Authority · 2025 · standard

  2. 2

    RFC 9110 - HTTP Semantics

    IETF / RFC Editor · 2022 · standard

Sources: IANA HTTP Status Code Registry · RFC 9110 - HTTP Semanticsreviewed 2026-10-19 · verified

Was this entry useful?