Remove file data from KumaScript rendering environment
Categories
(developer.mozilla.org Graveyard :: General, enhancement, P1)
Tracking
(Not tracked)
People
(Reporter: jwhitlock, Assigned: jwhitlock)
References
Details
(Whiteboard: [specification][type:change])
What feature should be changed? Please provide the URL of the feature if possible.
When Kuma calls KumaScript, it includes context data like the document path, revision ID, and tags as base64-encoded headers in the HTTP request. One of these headers is data about attachments, including filename, URL, title, description, size, author, and MIME type. This was added for bug 773285 in PR 413, presumably because macros migrated from DekiWiki macros used this information.
In node 10.14.0, the maximum header size was reduced from 80K to 8K, to prevent a denial of service attack. The encoded file information requires an HTTP header that exceeds 8K on some pages, resulting in the KumaScript service returning a 400 error for these pages. Rendering of pages with many attachments are broken, even if they don't contain macros that use this data.
Irene noticed this issue when adding new images on:
- https://developer.mozilla.org/en-US/docs/Tools/Web_Console/Rich_output
- https://developer.mozilla.org/en-US/docs/Tools/Web_Console/The_command_line_interpreter
The file information is currently used in two macros, Embed_text and EmbedSVG. These macros are used on about 50 translations, but only one English page, Web/SVG/Attribute/requiredFeatures, and the use on that page is broken, probably since the page move in June 2013.
This feature should be retired in steps:
- The file data reduced to filename and URL, the two data items used by
{{Embed_text}}and{{EmbedSVG}}. The duplicate nameattachmentsshould be removed. This should help all pages get before - The macros should be retired, or changed to use the attachment URL (https://mdn.mozillademos.org/files/3286/requiredFeatures.svg) rather than the file data in the environment.
- The file data should be dropped from the headers passed to KumaScript
What problems would this solve?
Pages with many attachments will render without a 400 error. We'd close off a way to break a page by adding an attachment with a very large description.
Who would use this?
Editors
What would users see?
Pages with many attachments will continue rendering
What would users do? What would happen as a result?
Continue not worrying about attachments
Is there anything else we should know?
node 10.15.0 added an option --max-http-header-size that could be used to increase the limit. However, given the low usage of the file data, I believe it makes more sense to drop it from the default environment passed to Kumascript, and add the data to the $json API if needed by macros.
|
||
Comment 1•6 years ago
|
||
|
||
Comment 2•6 years ago
|
||
I've filed https://github.com/mdn/kumascript/pull/1040 to remove {{Embed_text}} and {{EmbedSVG}}.
|
Assignee | |
Comment 3•6 years ago
|
||
Thanks wbamberg!
The two problem pages now render:
- https://developer.mozilla.org/en-US/docs/Tools/Web_Console/Rich_output
- https://developer.mozilla.org/en-US/docs/Tools/Web_Console/The_command_line_interpreter
I'm leaving the bug open for follow-on actions once these macros are gone.
|
|
Assignee | |
Comment 4•6 years ago
•
|
||
There are still documents with many attachments that get the 400 error. Most are user pages, but two stand out:
- https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor
- https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/theme
These should be fixed when we remove the file data header entirely.
|
|
Assignee | |
Updated•6 years ago
|
|
|
||
Comment 5•6 years ago
|
||
|
|
Assignee | |
Comment 6•6 years ago
|
||
With the file header gone, the pages now render without errors:
|
||
Updated•5 years ago
|
Description
•