There's significant traffic ATM for thumbnails with '0px' dimensions, mediawiki barfs with 500 on such requests. In this case the client is at fault though and mw should reply with 400 on bad parameters, not 500. Thumbor isn't affected and returns 400 instead.
Description
Description
Details
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Serve 400 instead of 500 when invalid thumbnail parameters are requested | mediawiki/core | master | +14 -0 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T147648 Unexplained increase in thumbnail 500s | |||
| Resolved | • Gilles | T147784 Mediawiki thumbnail requests for 0px should result in http 400 not 500 |
Event Timeline
Comment Actions
There's still significant traffic for 0px thumbs resulting in 500s, it'd be helpful I think if MW returned 400 here since there's nothing we can do about it really
Comment Actions
I think either 404 or 410 might be more appropriate. Typically 400 is for malformed requests in the HTTP sense (as in, unparseable/illegal request line), as opposed to undesirable query parameter values.
Comment Actions
Looking at https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html the definition of 400 seems more accurate than 410. The definition of 400 is broad and doesn't imply at what level the syntax is incorrect. The definition of 410 implies that the resource was there at some point in the past.
Mediawiki already returns 400s for other incorrect thumbnail parameters. Example: https://upload.wikimedia.org/wikipedia/commons/thumb/c/c1/Catedral_de_Gniezno%2C_Gniezno%2C_Polonia%2C_2014-09-17%2C_DD_19-21_HDR.jpg/foopx-Catedral_de_Gniezno%2C_Gniezno%2C_Polonia%2C_2014-09-17%2C_DD_19-21_HDR.jpg
Comment Actions
Change 323385 had a related patch set uploaded (by Gilles):
Serve 400 instead of 500 when invalid thumbnail parameters are requested
Comment Actions
Change 323385 merged by jenkins-bot:
Serve 400 instead of 500 when invalid thumbnail parameters are requested