For this there are RFC , these are technical documents developed and maintained by the Internet Enginnering Task Force (IETF), an institution that specifies the standards that will be implemented and used throughout the internet.
According to RFC 2616 , section 10 :
10.3.5 304 Not Modified
If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the SHOULD server responds with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.
The response MUST include the following header fields:
-
Date, unless its omission is required by section 14.18.1
If a clockless origin server obeys these rules, and proxies and clients add their own date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly.
-
ETag and / or Content-Location, if the header would have been sent
in 200 response to the same request
- Expires, Cache-Control, and / or Vary, if the field-value might
differ from that in any previous response for the same
variant
If the conditional GET used a strong cache validator (see section 13.3.3), the SHOULD response does NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.
If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.
If a cache uses a received 304 response to update the cache entry, the cache MUST update the entry to reflect any new field values given in the response.
Summarizing
For your answer, you can use 304
since the user's request will not change anything on the server and you're just returning the image.
Sources: