Bad request 400 when cloning a big export template #11736

New Issue

adam · 2025-12-29T21:49:16+01:00

adam commented

2025-12-29 21:49:16 +01:00

Originally created by @4ydan on GitHub (Oct 16, 2025).

NetBox Edition

NetBox Community

NetBox Version

v4.4.1

Python Version

3.11

Steps to Reproduce

Have an export template with > 4094 characters
Try to clone it.

Expected Behavior

I am in the view of creating a new export template, cloned from the selected one before.

Observed Behavior

Bad Request

Request Line is too large (7050 > 4094)

Originally created by @4ydan on GitHub (Oct 16, 2025). ### NetBox Edition NetBox Community ### NetBox Version v4.4.1 ### Python Version 3.11 ### Steps to Reproduce Have an export template with > 4094 characters Try to clone it. ### Expected Behavior I am in the view of creating a new export template, cloned from the selected one before. ### Observed Behavior Bad Request Request Line is too large (7050 > 4094)

adam added the type: bug label 2025-12-29 21:49:16 +01:00

adam closed this issue

2025-12-29 21:49:16 +01:00

adam commented

2025-12-29 21:49:17 +01:00

@jnovinger commented on GitHub (Oct 16, 2025):

@4ydan's diagnosis is likely correct, but also dependent on how his NetBox instance is being run. RFC 7230 recommends servers support at least 8KB request lines but doesn't mandate it. Common defaults are 4-8KB for nginx, 8KB for Apache.

The clone button builds its URL by serializing all clone_fields as query parameters. ExportTemplate includes template_code in clone_fields, which is a TextField with no size limit. When you URL-encode a Jinja template (lots of {, %, newlines), it expands by about 70%. A 4KB template likely becomes a 7KB URL, which exceeds the 4KB request line limit the reporter's environment enforces. The same issue affects ConfigContext.data, which can easily hit multi-KB sizes with realistic device configurations.

There's no fix to NetBox itself that preserves current functionality without changing how cloning works. You can't fit unbounded data through a size-limited channel. The options are:

Remove template_code from clone_fields. Clone button still works but users copy/paste the template content manually. Fixes the error but removes the main value of cloning a template.
Tell users to increase their web server limits. Just moves the problem and makes NetBox deployment-dependent. This is the reality of the current situation.
Change the cloning mechanism for large-data models. Something like posting to /export-templates/<pk>/clone/ where the backend handles duplication instead of passing everything through URL params. This works but changes behavior: the current approach lets you bookmark a clone URL as a point-in-time snapshot, while an ID-based approach makes bookmarked URLs always reference the current state of the source object. Though realistically, 7KB URLs were never bookmarkable anyway.

It's worth noting this hasn't been reported until now, so it's an edge case. If there's actually interest in changing this, that probably means introducing a different cloning mechanism for models with large fields, but that's a bigger discussion about whether the behavioral change is acceptable and would require a separate FR issue.

@jnovinger commented on GitHub (Oct 16, 2025): @4ydan's diagnosis is likely correct, but also dependent on how his NetBox instance is being run. RFC 7230 recommends servers support at least 8KB request lines but doesn't mandate it. Common defaults are 4-8KB for nginx, 8KB for Apache. The clone button builds its URL by serializing all `clone_fields` as query parameters. ExportTemplate includes `template_code` in `clone_fields`, which is a `TextField` with no size limit. When you URL-encode a Jinja template (lots of `{`, `%`, newlines), it expands by about 70%. A 4KB template likely becomes a 7KB URL, which exceeds the 4KB request line limit the reporter's environment enforces. The same issue affects `ConfigContext.data`, which can easily hit multi-KB sizes with realistic device configurations. There's no fix to NetBox itself that preserves current functionality without changing how cloning works. You can't fit unbounded data through a size-limited channel. The options are: - **Remove `template_code` from `clone_fields`.** Clone button still works but users copy/paste the template content manually. Fixes the error but removes the main value of cloning a template. - **Tell users to increase their web server limits.** Just moves the problem and makes NetBox deployment-dependent. This is the reality of the current situation. - **Change the cloning mechanism for large-data models.** Something like posting to `/export-templates/<pk>/clone/` where the backend handles duplication instead of passing everything through URL params. This works but changes behavior: the current approach lets you bookmark a clone URL as a point-in-time snapshot, while an ID-based approach makes bookmarked URLs always reference the current state of the source object. Though realistically, 7KB URLs were never bookmarkable anyway. It's worth noting this hasn't been reported until now, so it's an edge case. If there's actually interest in changing this, that probably means introducing a different cloning mechanism for models with large fields, but that's a bigger discussion about whether the behavioral change is acceptable and would require a separate FR issue.

adam commented

2025-12-29 21:49:17 +01:00

@jnovinger commented on GitHub (Oct 16, 2025):

To the point above about the current situation, some quick searching seems to indicate this originates from Gunicorn and the actual size is configurable (note: "from 0 (unlimited) to 8190"). Note that increasing it to a large enough size probably just moves to whatever is proxying requests in front of Gunicorn and will require changes at that level as well.

Since this is an installation dependent issue, I'm going to close this as 'not planned'. If anyone would truly like to see this behavior changed, then file an FR with a concrete proposal.

@jnovinger commented on GitHub (Oct 16, 2025): To the point above about the current situation, some quick searching seems to indicate this [originates from Gunicorn](https://github.com/benoitc/gunicorn/blob/56b5ad87f8d72a674145c273ed8f547513c2b409/gunicorn/http/errors.py#L108-L114) and the actual size is [configurable](https://docs.gunicorn.org/en/latest/settings.html#limit-request-line) (note: "from 0 (unlimited) to 8190"). Note that increasing it to a large enough size probably just moves to whatever is proxying requests in front of Gunicorn and will require changes at that level as well. Since this is an installation dependent issue, I'm going to close this as 'not planned'. If anyone would truly like to see this behavior changed, then file an FR with a concrete proposal.

Sign in to join this conversation.

Branches Tags

main

update-changelog-comments-docs

feature-removal-issue-type

20911-dropdown

20239-plugin-menu-classes-mutable-state

21097-graphql-id-lookups

feature

fix_module_substitution

20923-dcim-templates

20044-elevation-stuck-lightmode

feature-ip-prefix-link

v4.5-beta1-release

20068-import-moduletype-attrs

20766-fix-german-translation-code-literals

20378-del-script

7604-filter-modifiers-v3

circuit-swap

12318-case-insensitive-uniqueness

20637-improve-device-q-filter

20660-script-load

19724-graphql

20614-update-ruff

14884-script

02496-max-page

19720-macaddress-interface-generic-relation

19408-circuit-terminations-export-templates

20203-openapi-check

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/netbox#11736