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. One of these headers is data about attachments, including filename, URL, title, description, size, author, and MIME type. This was added for bug 773285 [PR 413](https://github.com/mozilla/kuma/pull/413), presumably because macros migrated from DekiWiki macros this information. In node 10.14.0, the maximum header size was reduced from 80K to 8K, to prevent a [denial of service attack](https://nodejs.org/en/blog/vulnerability/november-2018-security-releases/#denial-of-service-with-large-http-headers-cve-2018-12121). The encoded file information 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](https://github.com/mdn/kumascript/blob/master/macros/Embed_text.ejs) and [EmbedSVG](https://github.com/mdn/kumascript/blob/master/macros/EmbedSVG.ejs). These macros are used on about 50 translations, but only one English page, [Web/SVG/Attribute/requiredFeatures](https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/requiredFeatures), and the use on that page [is broken](https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/requiredFeatures#Elements), 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 name `attachments` should 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](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V10.md#2018-12-26-version-10150-dubnium-lts-mylesborins) 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.
Bug 1520574 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
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 [PR 413](https://github.com/mozilla/kuma/pull/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](https://nodejs.org/en/blog/vulnerability/november-2018-security-releases/#denial-of-service-with-large-http-headers-cve-2018-12121). 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](https://github.com/mdn/kumascript/blob/master/macros/Embed_text.ejs) and [EmbedSVG](https://github.com/mdn/kumascript/blob/master/macros/EmbedSVG.ejs). These macros are used on about 50 translations, but only one English page, [Web/SVG/Attribute/requiredFeatures](https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/requiredFeatures), and the use on that page [is broken](https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/requiredFeatures#Elements), 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 name `attachments` should 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](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V10.md#2018-12-26-version-10150-dubnium-lts-mylesborins) 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.
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](https://github.com/mozilla/kuma/pull/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](https://nodejs.org/en/blog/vulnerability/november-2018-security-releases/#denial-of-service-with-large-http-headers-cve-2018-12121). 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](https://github.com/mdn/kumascript/blob/master/macros/Embed_text.ejs) and [EmbedSVG](https://github.com/mdn/kumascript/blob/master/macros/EmbedSVG.ejs). These macros are used on about 50 translations, but only one English page, [Web/SVG/Attribute/requiredFeatures](https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/requiredFeatures), and the use on that page [is broken](https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/requiredFeatures#Elements), 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 name `attachments` should 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](https://github.com/nodejs/node/blob/master/doc/changelogs/CHANGELOG_V10.md#2018-12-26-version-10150-dubnium-lts-mylesborins) 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.