Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Misleading 5xx errors: `application/ld+json` bodies are never parsed, and bodied `DELETE /delete` 404s upstream

Đang mở
  • Có gì không ổn?
#129 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
express, javascript, nodejs
Lĩnh vực
api, backend

Hướng nghiên cứu

Bắt đầu với app.js và rest.js để theo dõi hành vi của content-type và body-parser đối với content-type và body, sau đó kiểm tra routes/create.js, routes/query.js và routes/delete.js. Chạy các bài kiểm thử route hiện có và tái hiện cả hai trường hợp bằng các lệnh curl được cung cấp. Được xem là hoàn tất khi hành vi ld+json nhất quán và đã được kiểm thử, đồng thời contract của DELETE có body được xác nhận và không còn báo cáo một lỗi upstream gây hiểu lầm.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

bug

Summary

While smoke testing the package updates on the 8-24-26-packages branch, two separate 502-producing
defects turned up. Neither is caused by the dependency bumps — both reproduce on main as well. They
are filed together because both were found the same way, but they are independent problems.

The first one is the more serious of the two: every route mishandles application/ld+json, and
/create leaks a raw TypeError to the client as a 500.

Finding 1: application/ld+json passes the content-type gate but is never parsed

rest.js accepts application/ld+json as a valid request content type
(rest.js#L1-L4), so verifyJsonContentType lets the request through
instead of returning 415. But app.js only mounts express.json()
(app.js#L20), whose body-parser type option defaults to
application/json and does not match the +json structured suffix. express.text() on the next
line only claims text/plain.

The result is that no parser claims the body, so req.body is undefined (Express 5 no longer
defaults it to {}), and every route then misbehaves in its own way.

Reproduction

Every request below sends a well-formed JSON body with a valid @id, and differs from a working
request only in the Content-Type header:

curl -X POST -H 'Content-Type: application/ld+json' \
  --data '{"@id":"https://devstore.rerum.io/v1/id/000000000000000000000000","type":"Probe"}' \
  http://localhost:3002/create
Observed behavior
Route Status Response body
POST /query 502 400: .../query?limit=10&skip=0 - Detected empty JSON object.
POST /create 500 Cannot read properties of undefined (reading 'id')
PUT /update 400 No record id to update!
PUT /overwrite 400 No record id to overwrite!
DELETE /delete 400 No record id to delete!

The identical body sent as application/json returns 200/201 as expected.

Why each is wrong
  • /create returns 500 and leaks an internal error. req.body.id on
    routes/create.js#L12 throws a TypeError against undefined. The route's
    catch has no err.status, so it falls through to 500 and sends the raw V8 message
    (Cannot read properties of undefined (reading 'id')) to the client. That is an internal
    implementation detail on the wire, and it contradicts our own guidance about returning generic
    error messages rather than internal details.
  • /query returns 502. JSON.stringify(undefined) is undefined, not '{}', so the empty-query
    guard on routes/query.js#L16 is bypassed. The request is forwarded upstream
    with no body, RERUM 400s, and TinyNode maps that to 502 — reporting an upstream failure for what is
    really a client error we should have caught.
  • /update, /overwrite, /delete return a misleading 400. The status code is defensible, but
    the message tells the caller they omitted a record id when they plainly supplied one. That will send
    people debugging the wrong thing.
Suggested fix

Either accept ld+json properly or reject it, but stop doing both. Accepting it is the smaller change
and matches what rest.js already advertises:

app.use(express.json({ type: ["application/json", "application/ld+json"] }))

Given this is a JSON-LD store, accepting it seems clearly correct. Worth deciding separately whether
/create should also guard req.body defensively so a missing body can never produce a raw
TypeError again — the same class of bug would resurface for any future unparsed content type.

This is a gap left by #110, which introduced rest.js and the ld+json allowance without a matching
parser change.

Finding 2: bodied DELETE /delete returns 502 because the upstream endpoint does not exist

The legacy bodied-delete handler (routes/delete.js#L27) posts to
${RERUM_API_ADDR}delete. That endpoint does not exist on devstore — it 404s, and TinyNode maps the
404 to a 502.

Reproduction
# create something to delete, then:
curl -X DELETE -H 'Content-Type: application/json' \
  --data '{"@id":"https://devstore.rerum.io/v1/id/<id>"}' \
  http://localhost:3002/delete
# -> HTTP 502
#    404: https://devstore.rerum.io/v1/api/delete - This page does not exist

Confirmed against RERUM directly, so this is upstream and not a TinyNode routing mistake:

curl -i -X DELETE -H 'Content-Type: application/json' \
  --data '{"@id":"..."}' https://devstore.rerum.io/v1/api/delete
# -> HTTP 404

The path form works correctly:

curl -X DELETE http://localhost:3002/delete/<id>
# -> HTTP 204
What to decide

This route cannot succeed against devstore in its current form, so one of the following is needed:

  • Confirm whether /v1/api/delete with a body is supposed to exist on RERUM. If it is, this is a
    RERUM bug and TinyNode is fine.
  • If it is not coming back, have the bodied handler extract the id from @id and delegate to the
    path form, so the documented legacy call keeps working.
  • Failing both, deprecate the bodied form and return a 400 that says so, rather than a 502 that
    implies an upstream outage.

Related to #89, which covers different odd behavior on the same endpoint (a delete with no id
returning 204). That specific case now correctly returns 400, so #89 may be partly stale.

Environment

  • Branch 8-24-26-packages, also reproduces on main
  • Node v24.19.0, npm 12.0.2
  • RERUM_API_ADDR=https://devstore.rerum.io/v1/api/
  • All 80 route tests and 5 e2e tests pass, so neither defect is currently covered by a test
Ngôn ngữ chính
JavaScript
Star
1
Fork
3
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của CenterForDigitalHumanities/TinyNode

Tất cả issue của CenterForDigitalHumanities/TinyNode

Issue tương tự

Thêm issue về JavaScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.