docs(sdk): Add foundations/transport section

develop-docs/sdk/foundations/index.mdx

@@ -0,0 +1,9 @@
+---
+title: Foundations
+description: Core concepts and infrastructure that every SDK builds on - transport protocol, data model, contexts, scopes, and attributes.
+sidebar_order: 2
+---
+
+The building blocks every SDK depends on. Understand how SDKs communicate with Sentry and the data structures they share.
+
+<PageGrid />

develop-docs/sdk/foundations/overview.mdx

@@ -0,0 +1,91 @@
+---
+title: Overview
+description: What an SDK is, what it does, and how end-users interact with it.
+sidebar_order: 1
+---
+
+## Writing an SDK
+
+At its core an SDK is a set of utilities for capturing data about an exceptional state in an application. Given this data, it then builds and sends a JSON payload to the Sentry server.
+
+The following items are expected of production-ready SDKs:
+
+-   DSN configuration
+-   Graceful failures (e.g. Sentry server is unreachable)
+-   Setting attributes (e.g. tags and extra data)
+-   Support for Linux, Windows and OS X (where applicable)
+
+Feature based support is required for the following:
+
+-   If cookie data is available, it's not sent by default
+-   If POST data is available, it's not sent by default
+
+Additionally, the following features are highly encouraged:
+
+-   Automated error capturing (e.g. uncaught exception handlers)
+-   Logging framework integration
+-   Non-blocking event submission
+-   Context data helpers (e.g. setting the current user, recording breadcrumbs)
+-   Event sampling
+-   Honor Sentry's [Rate Limiting](/sdk/foundations/transport/rate-limiting/) HTTP headers
+-   Pre and Post event send hooks
+-   Local variable values in stack trace (on platforms where this is possible)
+-   Send an `environment` on each event. If none was detected or set by the user, `production` should be used.
+
+Please see the <Link to="/sdk/expected-features#features">expected features page</Link> for descriptions of commonly Sentry SDK features.
+
+## Usage for End-users
+
+Generally, using an SDK consists of three steps for the end user, which should look almost identical no matter the language:
+
+1.  Initialization of the SDK (sometimes this is hidden from the user):
+
+    ```javascript
+    Sentry.init({dsn: '___PROJECT.DSN___'});
+    ```
+
+    ```python
+    sentry_sdk.init('___PROJECT.DSN___')
+    ```
+
+2.  Capturing an event:
+
+    ```javascript
+    var resultId = Sentry.captureException(myException);
+    ```
+
+    ```python
+    result_id = sentry_sdk.capture_exception(my_exception);
+    ```
+
+3.  Using the result of an event capture:
+
+    ```javascript
+    alert(`Your exception was recorded as ${resultId}`);
+    ```
+
+    ```python
+    print('Your exception was recorded as %s', result_id);
+    ```
+
+`init` ideally allows several configuration methods. The first argument should always be the DSN value (if possible):
+
+```javascript
+Sentry.init({
+    'dsn': '___PROJECT.DSN___',
+    'foo': 'bar'
+})
+```
+
+<Alert title="Note">
+SDKs should accept an empty DSN as valid configuration.
+
+If an SDK is not initialized or if it is initialized with an empty DSN, the SDK should not send any data over the network, such as captured exceptions.
+Depending on the platform, the SDK may avoid performing unnecessary initialization work and reduce its runtime footprint to a minimum.
+</Alert>
+
+Additionally, you should provide global functions which allow for capturing of
+a basic message or exception:
+
+-   `Sentry.captureMessage(message)`
+-   `Sentry.captureException(exception)`

develop-docs/sdk/foundations/transport/authentication.mdx

@@ -0,0 +1,146 @@
+---
+title: Authentication
+description: DSN format, authentication headers, and HTTP conventions for communicating with Sentry.
+sidebar_order: 1
+---
+
+## Parsing the DSN
+
+SDKs are encouraged to allow arbitrary options via the constructor, but must allow the first argument as a DSN string. This string contains the following bits:
+
+```
+'{PROTOCOL}://{PUBLIC_KEY}:{SECRET_KEY}@{HOST}{PATH}/{PROJECT_ID}'
+```
+
+The final endpoint you'll be sending requests to is constructed per the following:
+
+```
+ {BASE_URI} = '{PROTOCOL}://{HOST}{PATH}'
+
+'{BASE_URI}/api/{PROJECT_ID}/{ENDPOINT}/'
+```
+
+Within the `HOST` segment you will find the ingest domain for your organization. For self-hosted instances this will be the base host of your instance, and for sentry.io it will contain a host in the pattern of `o{orgid}.ingest.{region}.sentry.io`. For US based accounts `o{orgid}.ingest.sentry.io` will also work.
+
+<Alert title="Note" level="warning">
+All segments, including PROJECT_ID, are of type String.
+</Alert>
+
+Sentry provides the following endpoints:
+
+- [/envelope/](../envelopes/) for any submission using Envelopes.
+- [`/minidump/`](https://docs.sentry.io/platforms/native/minidump/) for multipart requests containing Minidumps.
+- [`/unreal/`](https://docs.sentry.io/platforms/unreal/configuration/setup-crashreporter/) for Unreal
+  Engine 4 crash reports.
+- [`/playstation/`](https://docs.sentry.io/platforms/playstation/) for PlayStation crash reports.
+  <Alert title="Note" level="info">
+  The PlayStation endpoint has limited access and requires allowlisting. Support involves components that are part of a partnership with Sony which cannot be made public or redistributed. This endpoint is only available in SaaS.
+  </Alert>
+- [`/security/`](https://docs.sentry.io/error-reporting/security-policy-reporting/) for Browser
+  CSP reports, usually configured in a browser instead of an SDK.
+
+See the respective endpoints for information on how to compose proper request payloads.
+
+For example, given the following constructor:
+
+```javascript
+Sentry.init({dsn: 'https://public@sentry.example.com/1'})
+```
+
+You should parse the following settings:
+
+- URI = `https://sentry.example.com`
+- Public Key = `public`
+- Project ID = `1`
+
+The resulting POST request for a plain JSON payload would then transmit to:
+
+```
+'https://sentry.example.com/api/1/store/'
+```
+
+<Alert title="Note" level="warning">
+The secret part of the DSN is optional and effectively deprecated at this point. While clients are still supposed to honor it if supplied future versions of Sentry will entirely ignore it. The DSN parsing code must not require the secret key to be set.
+</Alert>
+
+## Authentication Header
+
+An authentication header is expected to be sent along with the message body, which acts as an ownership identifier:
+
+```
+X-Sentry-Auth: Sentry sentry_version=7,
+  sentry_client=<client version, arbitrary>,
+  sentry_key=<public api key>,
+  sentry_secret=<secret api key>
+```
+
+The `sentry_secret` must only be included if a secret key portion was contained in the DSN. Future versions of the protocol will fully deprecate the secret key.
+
+<Alert title="Note">
+You should include the SDK version string in the User-Agent portion of the header, and it will be used if `sentry_client` is not sent in the auth header.
+</Alert>
+
+In situations where it's not possible to send the custom `X-Sentry-Auth` header, it's possible to send these values via the querystring:
+
+```
+?sentry_version=7&sentry_key=<public api key>&sentry_secret=<secret api key>...
+```
+
+`sentry_key`
+
+: **Required.** The public key which should be provided as part of the SDK configuration.
+
+`sentry_version`
+
+: **Required.** The protocol version. The current version of the protocol is `7`.
+
+`sentry_client`
+
+: **Recommended.** An arbitrary string that identifies your SDK, including its version. The typical pattern for this is `client_name/client_version`. For example, the Python SDK might send this as `sentry.python/1.0`.
+
+`sentry_timestamp`
+
+: The unix timestamp representing the time at which this event was generated. *This key is effectively deprecated, and it is ignored on the receiving side. Use the [`sent_at` envelope header](../envelopes/#envelope-headers) instead.*
+
+`sentry_secret`
+
+: The secret key which should be provided as part of the SDK configuration. *This key is effectively deprecated, and no longer needs to be set. However, since it was required in older versions, it should still be allowed and passed through to Sentry if set.*
+
+## HTTP Headers
+
+We recommend always sending the following headers:
+
+- `content-type`
+- `content-length`
+- `user-agent`
+
+The following additional headers are permitted as per CORS policy:
+
+- `x-sentry-auth`
+- `x-requested-with`
+- `x-forwarded-for`
+- `origin`
+- `referer`
+- `accept`
+- `authentication`
+- `authorization`
+- `content-encoding`
+- `transfer-encoding`
+
+### User Agent
+
+All SDKs are expected to report their name and version via the `user-agent` header. The following format should be used (unless required or recommended differently by the platform, e.g. for browser SDKs, where the user agent header must be set by the browser itself):
+
+`{sdk-name}/{sdk-version}`
+
+For example:
+- `sentry.python/1.45.0`
+- `sentry.php/4.7.0`
+- `sentry-ruby/5.17.3`
+- `sentry.cocoa/8.24.0`
+
+Additional information about the runtime, operating system, and others can be appended as comments in parentheses, separated by `; ` (semicolon and space), like so:
+
+`{sdk-name}/{sdk-version} ({runtime-name} {runtime-version}; {os-name} {os-version})`
+
+There is no expectation towards the presence or order of fields. The user agent must not contain PII or otherwise sensitive data. In general it should not contain any information that is not already present in the payload.

develop-docs/sdk/foundations/transport/compression.mdx

@@ -0,0 +1,20 @@
+---
+title: Compression
+description: Request compression and transfer encoding for Sentry envelope submissions.
+sidebar_order: 4
+---
+
+## Request Compression
+
+SDKs are heavily encouraged to compress the request body before sending it to the server to keep the data small. The preferred method for this is to send a `content-encoding` header. The following content encodings are accepted by Relay and Sentry:
+
+- `gzip`: Using the [LZ77](http://en.wikipedia.org/wiki/LZ77_and_LZ78#LZ77) compression algorithm.
+- `deflate`: Using [zlib](http://tools.ietf.org/html/rfc1950) structure with the [deflate](http://tools.ietf.org/html/rfc1951) compression algorithm.
+- `br`: Using the [Brotli](https://en.wikipedia.org/wiki/Brotli) algorithm.
+- `zstd`: Using the [zstd](https://datatracker.ietf.org/doc/html/rfc8878) algorithm.
+
+## Transfer Encoding
+
+Transfer encoding is recommended for only very large requests. Set the header to `transfer-encoding: chunked`, which allows omission of the `content-length` header and requires the request body to be wrapped into chunk headers.
+
+See [MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Transfer-Encoding) for more details.

develop-docs/sdk/data-model/envelope-items.mdx → develop-docs/sdk/foundations/transport/envelope-items.mdx

@@ -1,13 +1,13 @@
 ---
 title: Envelope Items
-sidebar_order: 2
+sidebar_order: 3
 ---
 
 Each Envelope consists of headers and a potentially empty list of Items, each
 with their own headers. Which Headers are required depends on the Items in an
 Envelope. This section describes all Item types and their respective required
 headers. It is worth noting that the list of Item types doesn't match the data
-categories used for [rate limiting](/sdk/expected-features/rate-limiting/#definitions) and
+categories used for [rate limiting](/sdk/foundations/transport/rate-limiting/#definitions) and
 client reports.
 
 The type of an Item is declared in the `type` header, as well as the payload
@@ -263,7 +263,7 @@ project. Sentry uses this ID to render a Replay clip in the feedback UI.
 **Attaching Files:**
 
 You can attach files of any type to a feedback (screenshots, logs, documents, etc.) by sending them as
-[attachment items](/sdk/data-model/envelope-items/#attachment), with `event_id`
+[attachment items](/sdk/foundations/transport/envelope-items/#attachment), with `event_id`
 corresponding to the feedback item. We recommend sending the attachment items in the same
 Envelope as the feedback item.
 

develop-docs/sdk/data-model/envelopes.mdx → develop-docs/sdk/foundations/transport/envelopes.mdx

@@ -1,6 +1,6 @@
 ---
 title: Envelopes
-sidebar_order: 1
+sidebar_order: 2
 ---
 
 This document defines the Envelope and Item formats used by Sentry for data
@@ -44,7 +44,7 @@ POST /api/<project_id>/envelope/
 ## Serialization Format
 
 This section defines the Envelope data format and serialization. For details on
-data integrity and a list of valid Item types refer to [Envelope Items](/sdk/data-model/envelope-items/).
+data integrity and a list of valid Item types refer to [Envelope Items](/sdk/foundations/transport/envelope-items/).
 
 ### Prerequisites
 
@@ -101,7 +101,7 @@ Payload = { * } ;
   [Headers](#headers) section. Attributes defined in the Envelope header scope
   the contents of the Envelope and can be thought of as applying to all Items.
 - Based on the contents of the Envelope, certain header attributes may be
-  required. See [Envelope Items](/sdk/data-model/envelope-items/) for a specification of required
+  required. See [Envelope Items](/sdk/foundations/transport/envelope-items/) for a specification of required
   attributes.
 - **Items** comprise their own headers and a payload. There can be
   an arbitrary number of **Items** in an Envelope separated by a newline. An
@@ -184,7 +184,7 @@ There are two generic headers for every Item:
 `type`
 
 : **String, required.** Specifies the type of this Item and its contents. Based
-  on the Item type, more headers may be required. See [Envelope Items](/sdk/data-model/envelope-items/) for a list
+  on the Item type, more headers may be required. See [Envelope Items](/sdk/foundations/transport/envelope-items/) for a list
   of all Item types.
 
 `length`
@@ -297,7 +297,7 @@ EOF:**
 
 ## Data Model
 
-This section has been moved to [Envelope Items](/sdk/data-model/envelope-items/).
+This section has been moved to [Envelope Items](/sdk/foundations/transport/envelope-items/).
 ## Ingestion
 
 This section describes how to ingest Envelopes into Relay or Sentry. The main

develop-docs/sdk/foundations/transport/index.mdx

@@ -0,0 +1,50 @@
+---
+title: Transport
+description: How SDKs send data to Sentry - envelope format, authentication, compression, and rate limiting.
+sidebar_order: 1
+---
+
+The transport layer handles all communication between an SDK and the Sentry server. SDKs serialize data into [envelopes](envelopes/), [authenticate](authentication/) requests using DSN-derived credentials, optionally [compress](compression/) payloads, and respect [rate limits](rate-limiting/) communicated via response headers.
+
+## Reading the Response
+
+On success, you will receive an HTTP response from the server containing a JSON payload with information on the submitted payload:
+
+```http
+HTTP/1.1 200 OK
+Content-Type: application/json
+
+{
+  "id": "fc6d8c0c43fc4630ad850ee518f1b9d0"
+}
+```
+
+**Always** check for a `200` response, which confirms the message was delivered. A small level of validation happens immediately that may result in a different response code (and message).
+
+## Handling Server Errors
+
+SDKs **MUST** honor the `429` status code and not attempt sending until the `Retry-After` kicks in. SDKs **SHOULD** drop events if Sentry is unavailable instead of retrying.
+
+To debug an error during development, inspect the response headers and response body. For example, you may get a response similar to:
+
+```http
+HTTP/1.1 400 Bad Request
+Content-Type: application/json
+X-Sentry-Error: failed to read request body
+
+{
+  "detail":"failed to read request body",
+  "causes":[
+    "failed to decode zlib payload",
+    "corrupt deflate stream"
+  ]
+}
+```
+
+The `X-Sentry-Error` header and response body will not always contain a message, but they can still be helpful in debugging clients. When emitted, they will contain a precise error message, which is useful to identify root cause.
+
+<Alert title="Note">
+We do not recommend that SDKs retry event submissions automatically on error — not even if `Retry-After` is declared in the response headers. If a request fails once, it is very likely to fail again on the next attempt. Retrying too often may cause further rate limiting or blocking by the Sentry server.
+</Alert>
+
+<PageGrid />