API Returns a HTTP 301 for invalid POST / PATCH requests #1499

New Issue

adam · 2025-12-29T16:32:29+01:00

adam commented

2025-12-29 16:32:29 +01:00

Originally created by @woodjme on GitHub (Jan 19, 2018).

Issue type

[X] Bug report

Environment

Python version: 2.7.9
NetBox version: 2.2.7

Description

API returns HTTP 301 Move Permanently redirect when the trailing / is missing from a URL.

Sending a POST to URL such as https://netbox.co.uk/api/virtualization/virtual-machines/1 results in a 301 redirect to https://netbox.co.uk/api/virtualization/virtual-machines/1/.

This presents a problem when sending a POST or PATCH request as the RFC specification states:

Note: For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.

Source

The net result is after sending the POST request you end up receiving an HTTP 200 for a GET request returning the unmodified object. I'd make the case that this 301 should be changed to a 308 as the RFC specifications states:

A 308 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see RFC7234], Section 4.2.2). Note: This status code is similar to 301 (Moved Permanently) ([RFC7231], Section 6.4.2), except that it does not allow changing the request method from POST to GET

Source

Originally created by @woodjme on GitHub (Jan 19, 2018). ### Issue type [X] Bug report ### Environment * Python version: `2.7.9` * NetBox version: `2.2.7` ### Description API returns `HTTP 301 Move Permanently` redirect when the trailing `/` is missing from a URL. Sending a POST to URL such as https://netbox.co.uk/api/virtualization/virtual-machines/1 results in a `301` redirect to https://netbox.co.uk/api/virtualization/virtual-machines/1/. This presents a problem when sending a `POST` or `PATCH` request as the RFC specification states: > Note: For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead. [Source](https://tools.ietf.org/html/rfc7231#section-6.4.2) The net result is after sending the `POST` request you end up receiving an `HTTP 200` for a `GET` request returning the unmodified object. I'd make the case that this `301` should be changed to a `308` as the RFC specifications states: > A 308 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see RFC7234], Section 4.2.2). Note: This status code is similar to 301 (Moved Permanently) ([RFC7231], Section 6.4.2), except that it does not allow changing the request method from POST to GET [Source](https://tools.ietf.org/html/rfc7538)

adam added the type: feature label 2025-12-29 16:32:29 +01:00

adam closed this issue

2025-12-29 16:32:29 +01:00

adam commented

2025-12-29 16:32:29 +01:00

@jeremystretch commented on GitHub (Jan 19, 2018):

This behavior is a convenience function provided by the Django framework. We could set APPEND_SLASH=False to simply return a 404 for URLs given without the trailing slash, but this will likely confuse users who on occasion hand-type a URL and forget the slash.

To be clear, the only correct URL is the form with the trailing slash. (The redirect is merely a hint.) To avoid this problem entirely, just use the correct form.

@jeremystretch commented on GitHub (Jan 19, 2018): This behavior is a convenience function [provided by the Django framework](https://docs.djangoproject.com/en/1.11/ref/settings/#append-slash). We could set `APPEND_SLASH=False` to simply return a 404 for URLs given without the trailing slash, but this will likely confuse users who on occasion hand-type a URL and forget the slash. To be clear, the only _correct_ URL is the form with the trailing slash. (The redirect is merely a hint.) To avoid this problem entirely, just use the correct form.

adam commented

2025-12-29 16:32:29 +01:00

@jeremystretch commented on GitHub (Jan 30, 2018):

This was discussed briefly in the #netbox channel on the NetworkToCode Slack. It's probably best to leave this as is to avoid breaking other things. While I understand your point, I think it's reasonable to assert that an API consumer must always use the canonically appropriate URL form.

@jeremystretch commented on GitHub (Jan 30, 2018): This was discussed briefly in the #netbox channel on the NetworkToCode Slack. It's probably best to leave this as is to avoid breaking other things. While I understand your point, I think it's reasonable to assert that an API consumer must always use the canonically appropriate URL form.

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#1499