Skip to content

Commit 72e328b

Browse files
authored
PEP 694: Error responses conform to the :rfc:9457 format. (#4733)
* Error responses conform to the :rfc:`9457` format. As per suggestion: https://discuss.python.org/t/pep-694-pypi-upload-api-2-0-round-2/101483/32 * Fix `make lint` * Fix typo
1 parent 94320bb commit 72e328b

File tree

1 file changed

+29
-15
lines changed

1 file changed

+29
-15
lines changed

peps/pep-0694.rst

Lines changed: 29 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -84,8 +84,8 @@ In addition, there are a number of major issues with the legacy API:
8484

8585
The new upload API proposed in this PEP provides ways to solve all of these problems, either directly or
8686
through an extensible approach, allowing servers to implement features such as resumable and parallel uploads.
87-
This upload API this PEP proposes provides better error reporting, a more robust release testing experience,
88-
and atomic and simultaneous publishing of all release artifacts.
87+
This upload API this PEP proposes provides better and more standardized error reporting, a more robust release
88+
testing experience, and atomic and simultaneous publishing of all release artifacts.
8989

9090
Legacy API
9191
==========
@@ -274,17 +274,26 @@ are determined by the index operator.
274274
Errors
275275
------
276276

277+
Unless otherwise specified, all error (4xx and 5xx) responses from the server **MUST** use the :rfc:`9457`
278+
(Problem Details for HTTP APIs) format. In particular, the server **MUST** use the "Problem Details JSON
279+
Object" defined in :rfc:`Section 3 <9457#section-3>` and **SHOULD** use the ``application/problem+json`` media
280+
type in its responses.
281+
277282
Clients in general should be prepared to handle `HTTP response error status codes
278-
<https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status>`_ which **MAY** contain payloads of the
279-
the following format:
283+
<https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status>`_ which **SHOULD** contain payloads like
284+
the following, although note that the details are index-specific, as long as they conform to RFC 9457. By way
285+
of example, PyPI could return the following error body:
280286

281287
.. code-block:: json
282288
283289
{
290+
"type": "https://docs.pypi.org/api/errors/error-types#invalid-filename",
291+
"status": 400,
292+
"title": "The artifact used an invalid wheel file name format",
293+
"details": "See https://packaging.python.org/en/latest/specifications/binary-distribution-format/",
284294
"meta": {
285295
"api-version": "2.0"
286296
},
287-
"message": "...",
288297
"errors": [
289298
{
290299
"source": "...",
@@ -293,11 +302,12 @@ the following format:
293302
]
294303
}
295304
296-
Besides the standard ``meta`` key, this has the following top level keys:
305+
RFC 9457 defines ``type``, ``status``, ``title``, and ``details``. The ``meta`` and ``errors`` keys are
306+
"extension members", defined in :rfc:`Section 3.2 <9457#section-3.2>`. The index **SHOULD** include these
307+
extension members.
297308

298-
``message``
299-
A singular message that encapsulates all errors that may have happened on this
300-
request.
309+
``meta``
310+
The same request/response metadata structure as defined in the :ref:`publishing-session` description.
301311

302312
``errors``
303313
An array of specific errors, each of which contains a ``source`` key, which is a string that
@@ -683,14 +693,14 @@ The request looks like:
683693
Besides the standard ``meta`` key, the request JSON has the following additional keys:
684694

685695
``filename`` (**required**)
686-
The name of the file being uploaded. The filename **MUST** conform to either the `source
687-
distribution file name specification
696+
The name of the file being uploaded. The filename **MUST** conform to either the `source distribution
697+
file name specification
688698
<https://packaging.python.org/en/latest/specifications/source-distribution-format/#source-distribution-file-name>`_
689699
or the `binary distribution file name convention
690700
<https://packaging.python.org/en/latest/specifications/binary-distribution-format/#file-name-convention>`_.
691-
Indexes **SHOULD** validate these file names at the time of the request, returning a ``400 Bad
692-
Request`` error code, as described in the :ref:`session-errors` section when the file names do
693-
not conform.
701+
Indexes **SHOULD** validate these file names at the time of the request, returning a ``400 Bad Request``
702+
error code and an RFC 9457 style error body, as described in the :ref:`session-errors` section when the
703+
file names do not conform.
694704

695705
``size`` (**required**)
696706
The size in bytes of the file being uploaded.
@@ -1094,7 +1104,11 @@ as experience is gained operating Upload 2.0.
10941104
Change History
10951105
==============
10961106

1097-
* `23-Sep-2025 <TBD>`__
1107+
* `06-Dec-2025 <TBD>`__
1108+
1109+
* Error responses conform to the :rfc:`9457` format.
1110+
1111+
* `23-Sep-2025 <https://discuss.python.org/t/pep-694-pypi-upload-api-2-0-round-2/101483/31>`__
10981112

10991113
* Remove the ``nonce`` and ``gentoken()`` algorithm. Indexes are now responsible for generating
11001114
an cryptographically secure session token and obfuscated stage URL (but only if they support

0 commit comments

Comments
 (0)