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

The available IPs/prefixes API views return an HTTP 400 when no new objects can be provisioned #2134

New Issue
Closed
opened 2025-12-29 17:22:35 +01:00 by adam · 4 comments
adam commented 2025-12-29 17:22:35 +01:00
Owner
Copy Link

Originally created by @jeremystretch on GitHub (Nov 20, 2018).

Environment

  • Python version: 3.5.2
  • NetBox version: v2.5-beta1

Steps to Reproduce

  1. Create a new prefix 192.0.2.0/30 (do not select "is a pool")
  2. Create the IP addresses 192.0.2.1/30 and 192.0.2.2/30
  3. Issue the following API request to attempt creating the next available IP address within 192.0.2.0/30:
curl -X POST \
-H "Authorization: Token <token>" \
-H "Content-Type: application/json" \
-H "Accept: application/json; indent=4" \
http://<netbox>/api/ipam/prefixes/<prefix-id>/available-ips/ \
--data '{"prefix_length": 30}'

Expected Behavior

NetBox should acknowledge this as a valid request and return an appropriate response code.

Observed Behavior

NetBox returns an HTTP 400 response, which implies that the request was invalid. The request sent is valid, but cannot be fulfilled.

It seems like a code 204 (No Content) might be the most appropriate response.

Originally created by @jeremystretch on GitHub (Nov 20, 2018). ### Environment * Python version: 3.5.2 * NetBox version: v2.5-beta1 ### Steps to Reproduce 1. Create a new prefix 192.0.2.0/30 (do not select "is a pool") 2. Create the IP addresses 192.0.2.1/30 and 192.0.2.2/30 3. Issue the following API request to attempt creating the next available IP address within 192.0.2.0/30: ``` curl -X POST \ -H "Authorization: Token <token>" \ -H "Content-Type: application/json" \ -H "Accept: application/json; indent=4" \ http://<netbox>/api/ipam/prefixes/<prefix-id>/available-ips/ \ --data '{"prefix_length": 30}' ``` ### Expected Behavior NetBox should acknowledge this as a valid request and return an appropriate [response code](https://en.wikipedia.org/wiki/List_of_HTTP_status_codes). ### Observed Behavior NetBox returns an HTTP 400 response, which implies that the request was invalid. The request sent _is_ valid, but cannot be fulfilled. It seems like a code 204 (No Content) might be the most appropriate response.
adam added the type: bugstatus: accepted labels 2025-12-29 17:22:35 +01:00
adam closed this issue 2025-12-29 17:22:35 +01:00
adam commented 2025-12-29 17:22:36 +01:00
Author
Owner
Copy Link

@bdlamprecht commented on GitHub (Nov 20, 2018):

While not exactly self-explanatory, of all the available and supported HTTP response codes, this seems the most appropriate.

@bdlamprecht commented on GitHub (Nov 20, 2018): While not exactly self-explanatory, of all the available and supported HTTP response codes, this seems the most appropriate.
adam commented 2025-12-29 17:22:36 +01:00
Author
Owner
Copy Link

@zachmoody commented on GitHub (Nov 20, 2018):

Late to the party, but I think a 4XX is a perfectly fine response. A 2XX implies success, and clients will probably wonder where their IP is given a "successful" response. If we're seeking something more descriptive maybe a 409 would work? 418's also a strong contender 😆

@zachmoody commented on GitHub (Nov 20, 2018): Late to the party, but I think a 4XX is a perfectly fine response. A 2XX implies success, and clients will probably wonder where their IP is given a "successful" response. If we're seeking something more descriptive maybe a 409 would work? 418's also a strong contender :laughing:
adam commented 2025-12-29 17:22:36 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Nov 20, 2018):

I wanted to get away from the 400 because it typically implies that there's something wrong with the request itself. Technically the request itself is processed successfully, so I went with 204. It at least differs from a normal 200.

@jeremystretch commented on GitHub (Nov 20, 2018): I wanted to get away from the 400 because it typically implies that there's something wrong with the request itself. Technically the request itself is processed successfully, so I went with 204. It at least differs from a normal 200.
adam commented 2025-12-29 17:22:37 +01:00
Author
Owner
Copy Link

@zachmoody commented on GitHub (Nov 20, 2018):

I wanted to get away from the 400 because it typically implies that there's something wrong with the request itself.

Yeah, the client asked for an available IP in a prefix that was full. 😄

Only reason it raised an eyebrow is that the requests library populates an ok attribute if the status_code is < 400 and clients could be using that for error handling. Suppose they could just check for empty responses though.

@zachmoody commented on GitHub (Nov 20, 2018): > I wanted to get away from the 400 because it typically implies that there's something wrong with the request itself. Yeah, the client asked for an available IP in a prefix that was full. :smile: Only reason it raised an eyebrow is that the requests library populates an `ok` attribute if the status_code is < 400 and clients could be using that for error handling. Suppose they could just check for empty responses though.
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 status: accepted type: bug
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#2134
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?