mosaicstack/stack
1
0
Fork 0
Code Issues 74 Pull Requests 1 Actions Packages Projects Releases 15 Wiki Activity

glpi: list wrappers reject HTTP 206, GLPI's normal response to a ranged query #807

New Issue
Closed
opened 2026-07-16 21:48:16 +00:00 by jason.woltje · 0 comments
jason.woltje commented 2026-07-16 21:48:16 +00:00
Owner
Copy Link

Summary

The three GLPI list wrappers treat HTTP 206 Partial Content as a failure. GLPI
returns 206 as its normal, successful response to a ranged query, so these
wrappers hard-fail against a perfectly healthy GLPI instance. They are currently
unusable for their primary purpose.

Affected files

  • packages/mosaic/framework/tools/glpi/ticket-list.sh (line 58)
  • packages/mosaic/framework/tools/glpi/computer-list.sh (line 40)
  • packages/mosaic/framework/tools/glpi/user-list.sh (line 40)

All three build a ranged endpoint (?range=0-${LIMIT}) and then gate on:

if [[ "$http_code" != "200" ]]; then
  echo "Error: Failed to list tickets (HTTP $http_code)" >&2
  exit 1
fi

Because the query is ranged, GLPI answers 206, never 200.

Reproduce

Against any GLPI instance with credentials configured:

$ tools/glpi/ticket-list.sh
Error: Failed to list tickets (HTTP 206)

The same request via curl returns 206 with a complete, valid JSON array. The
API is healthy; only the status-code check is wrong.

Expected vs actual

  • Expected: the ranged list is parsed and printed.
  • Actual: exit 1 with a misleading "Failed to list" error, implying the GLPI
    instance or credentials are broken when neither is.

Fix

Accept 206 alongside 200 in all three:

# GLPI answers a ranged query with 206 Partial Content, not 200.
if [[ "$http_code" != "200" && "$http_code" != "206" ]]; then

Verified locally: with this change all three wrappers return correct data
(tickets, computers, and users) against a live GLPI instance.

Notes

  • session-init.sh and ticket-create.sh are not affected — they do not
    issue ranged queries, so 200/201 is correct for them.
  • Worth a follow-up: no test covers these wrappers against a 206. A regression
    test asserting 206 is treated as success would prevent a recurrence.
## Summary The three GLPI list wrappers treat HTTP `206 Partial Content` as a failure. GLPI returns `206` as its **normal, successful** response to a ranged query, so these wrappers hard-fail against a perfectly healthy GLPI instance. They are currently unusable for their primary purpose. ## Affected files - `packages/mosaic/framework/tools/glpi/ticket-list.sh` (line 58) - `packages/mosaic/framework/tools/glpi/computer-list.sh` (line 40) - `packages/mosaic/framework/tools/glpi/user-list.sh` (line 40) All three build a ranged endpoint (`?range=0-${LIMIT}`) and then gate on: ```bash if [[ "$http_code" != "200" ]]; then echo "Error: Failed to list tickets (HTTP $http_code)" >&2 exit 1 fi ``` Because the query is ranged, GLPI answers `206`, never `200`. ## Reproduce Against any GLPI instance with credentials configured: ```bash $ tools/glpi/ticket-list.sh Error: Failed to list tickets (HTTP 206) ``` The same request via curl returns `206` with a complete, valid JSON array. The API is healthy; only the status-code check is wrong. ## Expected vs actual - **Expected:** the ranged list is parsed and printed. - **Actual:** exit 1 with a misleading "Failed to list" error, implying the GLPI instance or credentials are broken when neither is. ## Fix Accept `206` alongside `200` in all three: ```bash # GLPI answers a ranged query with 206 Partial Content, not 200. if [[ "$http_code" != "200" && "$http_code" != "206" ]]; then ``` Verified locally: with this change all three wrappers return correct data (tickets, computers, and users) against a live GLPI instance. ## Notes - `session-init.sh` and `ticket-create.sh` are **not** affected — they do not issue ranged queries, so `200`/`201` is correct for them. - Worth a follow-up: no test covers these wrappers against a `206`. A regression test asserting `206` is treated as success would prevent a recurrence.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
jason.woltje
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#807
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?