recursal/MDN huggingface dataset:
Content-Type
============

**`Content-Type`** es la propiedad de cabecera (header) usada para indicar el media type (en-US) del recurso.

`Content-Type` dice al cliente que tipo de contenido será retornado. Los navegadores rastrearán `MIME` en algunos casos y no seguirán necesariamente el valor de este encabezado; para evitar este comportamiento, el encabezado `X-Content-Type-Options` se puede establecer en `nosniff`.

En solicitudes (tales como `POST` o `PUT`), el cliente indica al servidor que tipo de dato es enviado actualmente.

| Header type | Entity header (en-US) |
| --- | --- |
| Forbidden header name | no |
| CORS-safelisted response-header (en-US) | si |

Sintaxis
--------
```

Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something
```

Directivas
----------

`media-type`

El MIME type de el recurso o el dato.

charset

La codificación de caracteres.

boundary

Para entidades de tipo *multipart* la directiva `boundary` es obligatoria. Ella consiste en una secuencia de 1 a 70 caracteres de un conjunto conocido por su robustez en pasarelas de correo electrónico, y no pueden terminar con espacios en blanco. Es usada para encapsular los limites de los mensajes de múltiples partes.

Ejemplos
--------

### `Content-Type` in HTML forms

En una solicitud `POST` , que resulta del envio de un formulario html, el `Content-Type` de la solicitud es especificado como un atributo `enctype` del elemento `<form>` .


```html
<form action="/" method="post" enctype="multipart/form-data">
  <input type="text" name="description" value="some text" />
  <input type="file" name="myFile" />
  <button type="submit">Submit</button>
</form>
```


La solicitud se visualiza algo como esto (si tienes poco interes en los headers omite esto)
```

POST /foo HTTP/1.1
Content-Length: 68137
Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575

---------------------------974767299852498929531610575
Content-Disposition: form-data; name="description"

some text
---------------------------974767299852498929531610575
Content-Disposition: form-data; name="myFile"; filename="foo.txt"
Content-Type: text/plain

(content of the uploaded file foo.txt)
---------------------------974767299852498929531610575
```

Especificaciones
----------------

| Specification |
| --- |
| HTTP Semantics # status.206 |
| HTTP Semantics # field.content-type |

Compatibilidad con navegadores
------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Más sobre
---------

* `Accept` and `Accept-Charset` (en-US)
* `Content-Disposition`
* `206` Partial Content
* `X-Content-Type-Options`
Host
====

El encabezado de solicitud **`Host`** especifica el nombre de dominio del servidor (para hosting virtual), y (opcionalmente) el número de puerto TCP en el que el servidor esta escuchando.

Si no se provee un puerto, se usará el puerto por defecto para el servicio solicitado (e.j.: "80" para una URL HTTP).

El encabezado `Host` debe enviarse obligatoriamente en todas las solicitudes HTTP/1.1. Un código de error `400` (Petición mala) debería enviarse a cualquier solicitud HTTP/1.1 que no contiene o contiene más de un encabezado `Host`.

| Header type | Encabezado de solicitud |
| --- | --- |
| Forbidden header name | sí |

Sintaxis
--------
```

Host: <host>:<puerto>
```

Directivas
----------

<host>

el nombre de dominio del servidor (pata hosting virtual).

<puerto> Opcional

número de puerto TCP en el que el servidor está escuchando.

Ejemplos
--------
```

Host: developer.mozilla.org
```

Especificaciones
----------------

| Specification |
| --- |
| HTTP Semantics # field.host |

Compatibilidad con navegadores
------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Véase también
-------------

* `400`
* `<base>`
Access-Control-Expose-Headers
=============================

La cabecera de respuesta **`Access-Control-Expose-Headers`** indica qué cabeceras pueden ser expuestas como parte de la respuesta listando sus nombres.

Por defecto, solo se exponen las 7 cabeceras HTTP seguras (CORS-safelisted response headers (en-US), simple response headers (en-US)):

* `Cache-Control`
* `Content-Language` (en-US)
* `Content-Length`
* `Content-Type`
* `Expires`
* `Last-Modified` (en-US)
* `Pragma`

Si quieres que los clientes puedan acceder a otra cabeceras, tienes que listarlas usando la cabecera `Access-Control-Expose-Headers`

| Header type | Response header |
| --- | --- |
| Forbidden header name | no |

Sintaxis
--------
```

Access-Control-Expose-Headers: <header-name>, <header-name>, ...
Access-Control-Expose-Headers: *
```

Directivas
----------

<header-name>

Una lista de cabeceras expuestas que consiste en cero o mas nombres de cabeceras diferentes a simple response headers (en-US) que el recurso puede usar y pueden ser expuestas.

`*` (*wildcard*, comodín)

 El valor "`*`" solo funciona como comodín para peticiones sin credenciales (peticiones sin HTTP cookies o autenticación HTTP). Para peticiones con credenciales, se trata como el literal "`*`", sin semánticas especiales.
 La cabecera `Authorization` siempre se añadirá de manera explícita.
 *Vea cómo se añade en los ejemplos de más abajo*.


Ejemplos
--------

Para exponer una cabecera no simple, puedes especificar:
```

Access-Control-Expose-Headers: Content-Length
```


Para exponer cabeceras personalizadas, como `X-Kuma-Revision`, puedes especificar varias cabeceras separadas por coma:
```

Access-Control-Expose-Headers: Content-Length, X-Kuma-Revision
```


En peticiones sin credenciales puedes utilizar el valor comodín:
```

Access-Control-Expose-Headers: *
```


Si necesitas acceder (exponer) la cabecera `Authorization`, hay que añadirla de manera explícita:
```

Access-Control-Expose-Headers: *, Authorization
```

Especificaciones
----------------

| Specification |
| --- |
| Fetch Standard # http-access-control-expose-headers |

Compatibilidad con navegadores
------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Ver también
-----------

* `Access-Control-Allow-Headers`
* `Access-Control-Allow-Origin`
Accept
======

`La cabecera de pedido Accept` anuncia que tipo de contenido el cliente puede procesar, expresado como un tipo MIME. Usando negociación de contenido (en-US), el servidor selecciona una de las propuestas , la utiliza e informa al cliente de la elección a través de la cabecera de respuesta `Content-Type` .

Los navegadores configuran los valores adecuados en dependencia del contexto donde se ha hecho el pedido, por ejemplo: al solicitar una hoja de estilos CSS es configurado un valor diferente que cuando se solicita una imagen, un video o un script.

|  |  |
| --- | --- |
| Tipo de Cabecera | Request header (en-US) |
| Forbidden header name | no |
| CORS-safelisted request-header (en-US) | si |

Sintaxis
--------
```

Accept: <MIME_type>/<MIME_subtype>
Accept: <MIME_type>/*
Accept: */*

// Multiples tipos, priorizados con quality value (en-US) sintaxis:
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
```

Directivas
----------

`<MIME_type>/<MIME_subtype>`

Un único y preciso tipo MIME, como `text/html`.

`<MIME_type>/*`

 Un tipo MIME, pero con cualquier subtipo.
 Por ejmplo, image/\* comincide con:


* image/png
* image/svg
* image/gif

`*/*`

Culaquier tipo MIME

`;q=` (donde *q* es la importancia o peso)

Culaquier valor es colocado en orden de preferencia, expresada usando un valor de calidad (en-US) llamado *weight* (*peso* en español).

Ejemplos
--------
```

Accept: text/html

Accept: image/*

Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
```

Especificaciones
----------------

| Specification |
| --- |
| HTTP Semantics # field.accept |

Compatibilidad con navegadores
------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Tambien Ver
-----------

* Negociación de Contenido HTTP (en-US)
* Cabecera con el resultado de la negociación de contenido: `Content-Type`
* Otras cabeceras similares: `TE` (en-US), `Accept-Encoding` (en-US), `Accept-Charset` (en-US), `Accept-Language` (en-US)
Access-Control-Allow-Headers
============================

El encabezado de respuesta **`Access-Control-Allow-Headers`** es usado en la respuesta a una solicitud preflight para indicar cuáles encabezados HTTP pueden ser usados durante dicha solicitud.

Los encabezados simples (en-US), `Accept`, `Accept-Language` (en-US), `Content-Language` (en-US), `Content-Type` (pero sólo con un tipo MIME de sus valores analizados (ignorando los parámetros) de cualquier `application/x-www-form-urlencoded`, `multipart/form-data`, o `text/plain`), siempre están disponibles y no necesitan ser incluidos por este encabezado.

Este encabezado es necesario si la solicitud tiene un encabezado `Access-Control-Request-Headers` (en-US).

| Tipo de encabezado | Encabezado de respuesta |
| --- | --- |
| Nombre de encabezado prohibido | no |

Sintaxis
--------
```

Access-Control-Allow-Headers: <nombre-de-encabezado>, <nombre-de-encabezado>, ...
```

Directivas
----------

<nombre-de-encabezado>

Lista de los encabezados soportados separados por una coma.

Ejemplos
--------
```

Access-Control-Allow-Headers: X-Custom-Header
```

Especificaciones
----------------

| Specification |
| --- |
| Fetch Standard # http-access-control-allow-headers |

Compatibilidad con navegadores
------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Véase también
-------------

* `Access-Control-Allow-Origin`
* `Access-Control-Expose-Headers`
* `Access-Control-Allow-Methods`
* `Access-Control-Request-Headers` (en-US)
Pragma
======

El **`Pragma`** encabezado general HTTP / 1.0 es un encabezado específico de la implementación que puede tener varios efectos a lo largo de la cadena de solicitud-respuesta. Se utiliza para la compatibilidad con versiones anteriores de las memorias caché HTTP / 1.0 en las que el `Cache-Control` encabezado HTTP / 1.1 aún no está presente.

**Nota:** `Pragma` no se especifica para las respuestas HTTP y, por lo tanto, no es un reemplazo confiable para el `Cache-Control` encabezado HTTP / 1.1 general , aunque se comporta de la misma manera que `Cache-Control: no-cache`, si el `Cache-Control` campo del encabezado se omite en una solicitud. Utilice `Pragma`solo para compatibilidad con versiones anteriores con clientes HTTP / 1.0.


|  |  |
| --- | --- |
| Tipo de encabezado | General header, pero el comportamiento de
 respuesta no se especifica y, por lo tanto, es específico de la
 implementación.
  |
| Forbidden header name | no |
| CORS-safelisted response-header (en-US) | si |

Sintaxis
--------
```

Pragma: no-cache
```

Directiva
---------

no-cache

Igual que `Cache-Control: no-cache`. Hace que las cachés envíen la solicitud al servidor de origen para su validación antes de liberar una copia en caché.

Ejemplos
--------
```

Pragma: no-cache
```

Especificaciones
----------------

| Specification |
| --- |
| HTTP Caching # field.pragma |

Compatibilidad con navegadores
------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Véase también
-------------

* `Cache-Control`
* `Expires`
Content-Encoding
================

La cabecera **`Content-Encoding`** es usada para comprimir el media-type. Cuando está presente, su valor indica qué codificación de contenido adicional ha sido aplicada al cuerpo de la entidad. Permite al cliente saber cómo decodificar para obtener el media-type referido por la cabecera `Content-Type`.

Se recomienda comprimir los datos tanto como sea posible y por lo tanto utilizar este campo, pero algunos tipos de recursos, como imágenes JPEG, ya están comprimidos. A veces, el uso de compresión adicional no reduce el tamaño de la petición e incluso puede hacer que la petición sea más larga.

| Header type | Entity header (en-US) |
| --- | --- |
| Forbidden header name | no |

Sintaxis
--------
```

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: identity
Content-Encoding: br
```

Directivas
----------

`gzip`

Un formato que usa Lempel-Ziv coding (LZ77), con un CRC de 32 bits. Este es originalmente el formato del programa *gzip de* UNIX . El estándar HTTP/1.1 también recomienda que los servidores que soporten esta codificación también deberían reconocer `x-gzip` como un alias por motivos de compatibilidad.

`compress`

 Un formato que usa el algoritmo Lempel-Ziv-Welch (LZW). El nombre viene del programa *compress de* UNIX , que implementó este algoritmo.
 Al igual que el programa compress, el cual ha desaparecido de la mayoría de distribuciones UNIX, esta codificación apenas es utilizada por los navegadores de hoy día, en parte debido a un problema de patente (la cual expiró en 2003).


`deflate`

Usa la estructura zlib (definida en RFC 1950), con el algoritmo de compresión *deflate* (definido en RFC 1951).

`identity`

Indica la función de identidad (es decir, sin compresión ni modificación). Este símbolo, excepto si se especifica explícitamente, siempre se considera aceptable.

`br`

Un formato que usa el algoritmo Brotli.

Ejemplos
--------

### Comprimiendo con gzip

En el lado del cliente, puede detectar una lista de esquemas de compresión que serán enviados en una petición HTTP. La cabecera `Accept-Encoding` (en-US) se utiliza para la negociación de la codificación del contenido.
```

Accept-Encoding: gzip, deflate
```


El servidor responde con el esquema usado, indicado por la cabecera de respuesta `Content-Encoding`.
```

Content-Encoding: gzip
```


Ten en cuenta que el servidor no está obligado a usar algun método de compresión. La compresión depende directamente de la configuración del servidor y los módulos que utilice.

Especificaciones
----------------

| Especificación | Título |
| --- | --- |
| RFC 7231, sección 3.1.2.2: Content-Encoding | Hypertext Transfer Protocol (HTTP/1.1): Semántica y Contenido |
| http://www.ietf.org/id/draft-alakuijala-brotli | Formato de datos comprimidos Brotli |

Compatibilidad con los navegadores
----------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Ver también
-----------

* `Accept-Encoding` (en-US)
* `Transfer-Encoding`
Access-Control-Allow-Origin
===========================

El encabezado de respuesta **`Access-Control-Allow-Origin`** indica si los recursos de la respuesta pueden ser compartidos con el origen (en-US) dado.

|  |  |
| --- | --- |
| Tipo de encabezado | Encabezado de respuesta |
| Nombre de encabezado prohibido | no |

Sintaxis
--------
```

Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: <origen>
Access-Control-Allow-Origin: null
```

Directivas
----------

`*`

Para las peticiones *sin credenciales*, el servidor puede especificar el caracter "\*" como un comodín, permitiendo a cualquier origen acceder al recurso. El acceso será permitido solamente para las peticiones hechas con el atributo `crossorigin` definido como `"anonymous"`. Intentar usar el comodín con credenciales resultará en un error (en-US).

`<origen>`

Especifica que origen puede acceder al recurso. Sólo se puede especificar un origen.

Ejemplos
--------

Para permitir a cualquier origen el acceso a tus recursos, puedes especificar:
```

Access-Control-Allow-Origin: *
```


Una respuesta que le dice al navegador que permita la petición de código del origen `https://developer.mozilla.org` para acceder a los recursos que incluyan lo siguiente:
```

Access-Control-Allow-Origin: https://developer.mozilla.org
```


Limitando los posibles valores `Access-Control-Allow-Origin` de un conjunto de orígenes permitidos requiere código del lado del servidor para revisar el valor de la encabezado de petición `Origin`, comparan con la lista de valores permitidos, y entonces si el valor `Origin` se encuentra en la lista, para definir el valor de `Access-Control-Allow-Origin` al mismo valor que `Origin`.

### CORS y caché

Si el servidor envía una respuesta con un valor `Access-Control-Allow-Origin` que es un origen explícito (en lugar del comodín "`*`"), entonces a respuesta debería incluir también el encabezado de respuesta `Vary` con el valor `origin` - para indicar a los navegadores que las respuestas del servidor pueden diferir basadas en el valor del encabezado de respueta `Origin`.
```

Access-Control-Allow-Origin: https://developer.mozilla.org
Vary: Origin
```

Especificaciones
----------------

| Specification |
| --- |
| Fetch Standard # http-access-control-allow-origin |

Compatibilidad con navegadores
------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Veáse también
-------------

* `Origin`
* `Vary`
* Cross-Origin Resource Sharing (CORS)
Allow
=====

La cabecera **`Allow`** enumera el conjunto de métodos admitidos por un recurso.

Esta cabecera debe ser enviada si el servidor responde con un estado `405` `Method Not Allowed` para indicar cual metodo de peticion puede ser usado. Una cabecera `Allow` vacia indica que el recurso no permite ningún método de solicitud, que podría ocurrir temporalmente para un recurso determinado, por ejemplo.

| Header type | Entity header (en-US) |
| --- | --- |
| Forbidden header name | no |

Sintáxis
--------


```js
Allow: <http-methods>
```

Directivas
----------

<http-methods>

La lista de métodos de solicitud HTTP permitidos.

Ejemplo
-------
```

Allow: GET, POST, HEAD
```

Especificaciones
----------------

| Especificación | Título |
| --- | --- |
| RFC 7231, sección 7.4.1: Allow | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

Vea también
-----------

* `405`
* `Server`
X-Content-Type-Options
======================

El encabezado HTTP de respuesta **`X-Content-Type-Options`** es un marcador utilizado por el servidor para indicar que los tipos MIME anunciados en los encabezados `Content-Type` no se deben cambiar ni seguir. Esto permite desactivar el MIME type sniffing, o, en otras palabras, es una manera de decir que los webmasters sabían lo que estaban haciendo.

Este encabezado fue introducido por Microsoft en IE 8 para que los webmasters bloquearan el rastreo de contenido, pudiendo transformar tipos MIME no ejecutables en tipos MIME ejecutables. Desde entonces, otros navegadores lo han introducido, incluso con algoritmos de detección MIME menos agresivos.

Los evaluadores de seguridad del sitio suelen esperar que este encabezado aparezca.

**Nota:** `nosniff` solo se aplican a los tipos "`script`" y "`style`". Además la aplicación de `nosniff` a las imágenes resulto ser incompatible con los sitios web existentes.


| Header type | Response header |
| --- | --- |
| Forbidden header name | no |

Sintaxis
--------
```

X-Content-Type-Options: nosniff
```

Directivas
----------

`nosniff`

Bloquea una solicitud si el tipo solicitado es

* "`style`" y el tipo MIME no es "`text/css`", o
* "`script`" y el tipo MIME no es un JavaScript MIME type.

Especificaciones
----------------

| Specification |
| --- |
| Fetch Standard # x-content-type-options-header |

Compatibilidad con navegadores
------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Vea también
-----------

* `Content-Type`
* The original definition of X-Content-Type-Options by Microsoft.
* The Mozilla Observatory tool testing the configuration (including this header) of Web sites for safety and security
* Mitigating MIME Confusion Attacks in Firefox
Access-Control-Allow-Methods
============================

La cabecera de respuesta **`Access-Control-Allow-Methods`** especifica el método o los métodos aceptados cuando se accede al recurso en respuesta de un preflight request.

| Tipo de cabecera | Response header |
| --- | --- |
| Forbidden header name | no |

Sintaxis
--------
```

Access-Control-Allow-Methods: <method>, <method>, ...
```

Directivas
----------

<método>

Comma-delimited list of the allowed HTTP request methods.

Ejemplos
--------
```

Access-Control-Allow-Methods: POST, GET, OPTIONS
```

Especificaciones
----------------

| Specification |
| --- |
| Fetch Standard # http-access-control-allow-methods |

Compatibilidad con navegadores
------------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Access-Control-Allow-Origin`
* `Access-Control-Expose-Headers`
* `Access-Control-Allow-Headers`
* `Access-Control-Request-Method` (en-US)
X-Forwarded-For
===============

La cabecera **`X-Forwarded-For`** (XFF) es un estándar de facto para identificar el origen de la dirección IP de un cliente conectado a un servidor web a través de un proxy HTTP o un balanceador de carga. Cuando se intercepta el tráfico entre cliente y servidores, los registros de los servidores de acceso contienen sólo la dirección IP del proxy o del balanceador de carga. Para ver la dirección IP original del cliente, se utiliza la cabecera `X-Forwarded-For`.

Esta cabecera se usa para la depuración, estadísticas, y la generación de contenido dependiente de la ubicación. De forma deliberada, expone información privada sensible como la dirección IP del cliente. Por lo tanto, debe tenerse en cuenta la privacidad del usuario a la hora de publicar esta cabecera.

Una versión estandarizada de esta cabecera es la cabecera HTTP `Forwarded` (en-US).

`X-Forwarded-For` es también una cabecera de correo electrónico que indica que el mismo fue reenviado desde otra cuenta.

| Header type | Request header (en-US) |
| --- | --- |
| Forbidden header name | no |

Sintaxis
--------
```

X-Forwarded-For: <client>, <proxy1>, <proxy2>
```

Directivas
----------

<cliente>

La dirección IP del cliente

<proxy1>, <proxy2>

Si una solicitud pasa por varios proxies, las direcciones IP de cada proxy se listan en forma sucesiva. Esto significa que la IP de más a la derecha es la IP del proxy más reciente, y la IP de más a la izquierda es la IP del cliente originador.

Ejemplos
--------
```

X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348

X-Forwarded-For: 203.0.113.195

X-Forwarded-For: 203.0.113.195, 70.41.3.18, 150.172.238.178
```


Otras formas no estándar:
```

# Usado para algunos servicios de Google
X-ProxyUser-Ip: 203.0.113.19
```

Especificaciones
----------------

No es parte de especificación actual alguna. La versión estandarizada de este cabezal es `Forwarded` (en-US).

See also
--------

* `Forwarded` (en-US)
* `X-Forwarded-Host` (en-US)
* `X-Forwarded-Proto` (en-US)
* `Via` (en-US)