starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

HTTP 204 response with body - /ipam/prefixes/{id}/available-prefixes/ #4619

New Issue
Closed
opened 2025-12-29 18:38:20 +01:00 by adam · 9 comments
adam commented 2025-12-29 18:38:20 +01:00
Owner
Copy Link

Originally created by @stephan-windischmann on GitHub (Mar 3, 2021).

Environment

Python version: 3.7.9
NetBox version: v2.9.3

Steps to Reproduce

Use the /ipam/prefixes/{id}/available-prefixes/ API endpoint to create a new child prefix of a size that does not fit into the parent prefix anymore, either because it's too big or because the parent prefix no longer has enough space available.

The received response (HTTP 204 NOT FOUND) contains a body and does not conform to the HTTP standard.

Example:

  1. Create a new prefix
    image

  2. Create a child prefix of the newly created prefix that is too big to fit
    image

We get a HTTP 204 NOT FOUND response. As can be seen the response contains a body with error details. This goes against the HTTP specification.

Expected behavior

A fully standard compliant response

Observed Behavior

The /ipam/prefixes/{id}/available-prefixes/ endpoint an HTTP 204 error response when we do a POST request to create a child prefix and not enough space is available in the parent prefix.
This reponse contains a body:
{ "detail": "Insufficient space is available to accommodate the requested prefix size(s)" }
While some tools and libraries (e.g. Postman) handle this fine, the HTTP standard says that HTTP 204 responses must not contain a message body, so other HTTP libraries will not handle this response body well.

Originally created by @stephan-windischmann on GitHub (Mar 3, 2021). ### Environment Python version: 3.7.9 NetBox version: v2.9.3 ### Steps to Reproduce Use the /ipam/prefixes/{id}/available-prefixes/ API endpoint to create a new child prefix of a size that does not fit into the parent prefix anymore, either because it's too big or because the parent prefix no longer has enough space available. The received response (HTTP 204 NOT FOUND) contains a body and does not conform to the HTTP standard. Example: 1. Create a new prefix ![image](https://user-images.githubusercontent.com/10330771/109927547-ae061300-7cc4-11eb-9c35-db15a1645991.png) 2. Create a child prefix of the newly created prefix that is too big to fit ![image](https://user-images.githubusercontent.com/10330771/109927584-bb230200-7cc4-11eb-9cce-599e3f659849.png) We get a HTTP 204 NOT FOUND response. As can be seen the response contains a body with error details. This goes against the HTTP specification. ### Expected behavior A fully standard compliant response ### Observed Behavior The /ipam/prefixes/{id}/available-prefixes/ endpoint an HTTP 204 error response when we do a POST request to create a child prefix and not enough space is available in the parent prefix. This reponse contains a body: `{ "detail": "Insufficient space is available to accommodate the requested prefix size(s)" }` While some tools and libraries (e.g. Postman) handle this fine, the HTTP standard says that HTTP 204 responses must not contain a message body, so other HTTP libraries will not handle this response body well.
adam added the pending closure label 2025-12-29 18:38:20 +01:00
adam closed this issue 2025-12-29 18:38:20 +01:00
adam commented 2025-12-29 18:38:21 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 3, 2021):

This issue is pending closure as it does not conform to one of the provided templates as required by the contributing guide. If you'd like to request that your issue be re-opened, please first update the content so that it matches the appropriate template (this may require rewriting your issue entirely).

@jeremystretch commented on GitHub (Mar 3, 2021): This issue is pending closure as it does not conform to one of the [provided templates](https://github.com/netbox-community/netbox/issues/new/choose) as required by the [contributing guide](https://github.com/netbox-community/netbox/blob/master/CONTRIBUTING.md). If you'd like to request that your issue be re-opened, please first update the content so that it matches the appropriate template (this may require rewriting your issue entirely).
adam commented 2025-12-29 18:38:21 +01:00
Author
Owner
Copy Link

@stephan-windischmann commented on GitHub (Mar 3, 2021):

Issue updated to conform to template.

@stephan-windischmann commented on GitHub (Mar 3, 2021): Issue updated to conform to template.
adam commented 2025-12-29 18:38:21 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 4, 2021):

@stephan-windischmann thanks, but could you please specify exactly what prefix(es) you're creating and what requests you're making? This will allow someone else to positively reproduce the reported behavior.

@jeremystretch commented on GitHub (Mar 4, 2021): @stephan-windischmann thanks, but could you please specify exactly what prefix(es) you're creating and what requests you're making? This will allow someone else to positively reproduce the reported behavior.
adam commented 2025-12-29 18:38:21 +01:00
Author
Owner
Copy Link

@stephan-windischmann commented on GitHub (Mar 4, 2021):

Added steps to reproduce the behavior.

@stephan-windischmann commented on GitHub (Mar 4, 2021): Added steps to reproduce the behavior.
adam commented 2025-12-29 18:38:21 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Mar 4, 2021):

Looking at this, reviewing the HTTP spec, we probably should not be using HTTP_204_NO_CONTENT. However, I cannot find a more accurate response without tripping a error condition (which would be a breaking change).

@DanSheps commented on GitHub (Mar 4, 2021): Looking at this, reviewing the HTTP spec, we probably should not be using HTTP_204_NO_CONTENT. However, I cannot find a more accurate response without tripping a error condition (which would be a breaking change).
adam commented 2025-12-29 18:38:21 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Mar 4, 2021):

A fully standard compliant response

Which would be what, in your opinion?

@jeremystretch commented on GitHub (Mar 4, 2021): > A fully standard compliant response Which would be what, in your opinion?
adam commented 2025-12-29 18:38:22 +01:00
Author
Owner
Copy Link

@stephan-windischmann commented on GitHub (Mar 7, 2021):

I'd probably use 406 Not Acceptable or 503 Service Unavailable (or the more generic 500 Internal Server Error).

I admit, these responses aren't ideal either, but seem like a better choice than using 204.
2xx responses should only be used if the request was successful.

@stephan-windischmann commented on GitHub (Mar 7, 2021): I'd probably use 406 Not Acceptable or 503 Service Unavailable (or the more generic 500 Internal Server Error). I admit, these responses aren't ideal either, but seem like a better choice than using 204. 2xx responses should only be used if the request was successful.
adam commented 2025-12-29 18:38:22 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Apr 22, 2021):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Apr 22, 2021): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:38:22 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 22, 2021):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@github-actions[bot] commented on GitHub (May 22, 2021): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label pending closure
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#4619
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?