View Issue Details

IDProjectCategoryView StatusLast Update
0008492Talerexchangepublic2024-02-22 19:14
Reportersebasjm Assigned ToChristian Grothoff Resolution deadline
ImplementerReviewer 
Release signed byDeployed by 
VerifierCommunicator 
Data protection authority notification requiredNo  
CSIRT notification requiredNo  
Estimated effort (hours)Actual effort (hours)0 
Fast-trackNo
Work packagenone
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionwon't fix 
Product Versiongit (master) 
Target Version0.9.4Fixed in Version0.9.4 
Summary0008492: better ETAG for /terms
Descriptioncurrent etag is "exchange-tos-v0"

etag should have
 * version number
 * mime-type
 * lang

then when a request is made,if the client request header $LANG and $MIMETYPE does not match the etag (of the request) the server knows that it should respond with body content.

alternative: etag = md5(content) where content is defined with lang and mime-type (and server tos version)

problem today: if the client send a request with an etag and the etag correspond to the current server version then the exchange has no way to know that that etag is not correct given the $LANG and $TYPE of the current request

 
TagsNo tags attached.

Required notifications

Address or linkRemarkAdded byNotifiedActions

Activities

Christian Grothoff

2024-02-22 19:13

manager   ~0021463

No, you are doing etags wrong. We will NOT do that. The etag must NOT encode the things you propose, that breaks our design.

Christian Grothoff

2024-02-22 19:14

manager   ~0021464

If a client requires the /terms in another language/encoding, they should just request it and force-bypass the cache. Done. Etags are about the legal semantics, which *legal* version you have accepted.

Issue History

Date ModifiedUsernameFieldChange
2024-02-22 17:31sebasjmNew Issue
2024-02-22 17:31sebasjmStatusnew => assigned
2024-02-22 17:31sebasjmAssigned To => Christian Grothoff
2024-02-22 19:13Christian GrothoffNote Added: 0021463
2024-02-22 19:14Christian GrothoffNote Added: 0021464
2024-02-22 19:14Christian GrothoffStatusassigned => closed
2024-02-22 19:14Christian GrothoffResolutionopen => won't fix
2024-02-22 19:14Christian GrothoffFixed in Version => 0.9.4