I have express.js based server and working on implementing etag HTTP header. So, I find out express has already etag and 304 status code implementation enabled. I was going through the code as found two observations -

1. express uses etag npm library to get the sha1 hash of the response, and it generates same hash for both weak and strong etags except for the prefix "W/".
2. express uses fresh npm library to check the freshness of a response and it validates the etag header and if-none-match header with if check - if (match === etag || match === 'W/' + etag || 'W/' + match === etag) {return true}. Github link. It seems that weak or strong etags has same validations and will return true even if client sends weak etag and server generates strong etag, and vice versa.

So, is it weak kind of validation that is being used here? Also what extra advantage it will provide if we use app.set('etag', 'strong'); in our app?

P.S. My app generates HTML for the web pages which are dynamic and needs 304 status code implementation in it.

I have express.js based server and working on implementing etag HTTP header. So, I find out express has already etag and 304 status code implementation enabled. I was going through the code as found two observations -

1. express uses etag npm library to get the sha1 hash of the response, and it generates same hash for both weak and strong etags except for the prefix "W/".
2. express uses fresh npm library to check the freshness of a response and it validates the etag header and if-none-match header with if check - if (match === etag || match === 'W/' + etag || 'W/' + match === etag) {return true}. Github link. It seems that weak or strong etags has same validations and will return true even if client sends weak etag and server generates strong etag, and vice versa.

So, is it weak kind of validation that is being used here? Also what extra advantage it will provide if we use app.set('etag', 'strong'); in our app?

P.S. My app generates HTML for the web pages which are dynamic and needs 304 status code implementation in it.

• express
• http-headers
• etag
• http-caching
• http-status-code-304

1 Answer 1

The best way to understand this is to look at the specification, RFC 9110. Read Section 8.8.1, Weak versus Strong and I think you'll have a good handle on this topic.

"So, is it weak kind of validation that is being used here?"

Yes, when the ETags are compared without regard to the weakness prefix, that is a "weak match". For caching purposes that is all that's required.

"Also what extra advantage it will provide if we use app.set('etag', 'strong'); in our app?"

Based on your very brief description of your application it wouldn't make any difference. Strong validation is required in certain circumstances (like using ETags to safely update a resource), but if you're only concerned with caching it shouldn't matter. That said, using strong validators has a semantic meaning, so definitely don't use them unless you can meet the requirements in the standard: "A 'strong validator' is representation metadata that changes value whenever a change occurs to the representation data that would be observable in the content of a 200 (OK) response to GET."