¿Cuál es la respuesta correcta a una solicitud HTTP POST?

Question

Para un método POST, las especificaciones de W3 dicen:

  

Si se ha creado un recurso en el servidor de origen, la respuesta      DEBE ser 201 (creado) y contener una entidad que describa la      estado de la solicitud y se refiere al nuevo recurso, y una ubicación      encabezado (ver Sección 10.4).

http: //www.ietf. org / internet-drafts / draft-ietf-httpbis-p2-semantics-05.txt (sección 8.5)

La respuesta estándar parece ser enviar un redireccionamiento al recurso recién creado.

Estoy construyendo mi sitio con ASP.NET MVC, y traté de seguir la especificación, así que creé una clase ResourceCreatedResult :

public class ResourceCreatedResult : ActionResult
{
    public string Location { get; set; }
    public override void ExecuteResult(ControllerContext context)
    {
        context.HttpContext.Response.Clear();
        context.HttpContext.Response.StatusCode = 201;
        context.HttpContext.Response.ClearHeaders();
        context.HttpContext.Response.AddHeader("Location", Location);
    }
}

Y mi acción se ve más o menos así:

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult CreateNew(string entityStuff)
{
    Entity newEntity = new Entity(entityStuff);
    IEntityRepository entityRepository = ObjectFactory.GetInstance<IEntityRepository>();
    entityRepository.Add(newEntity);

    ActionResult result = new ResourceCreatedResult()
        { Location = Url.Action("Show", new { id = newEntity.Id }) };
    return result;
}

Sin embargo, IE, Firefox y Chrome no pueden redirigir al nuevo recurso. ¿He arruinado la generación de la respuesta correcta o los navegadores web no esperan este tipo de respuesta, en lugar de confiar en los servidores para enviar una respuesta de redirección?

Answer 1

Redirigir después de publicar o publicar / redirigir / obtener es algo que su aplicación debe hacer para que sea fácil de usar.

Editar . Esto está por encima y más allá de las especificaciones HTTP. Si simplemente devolvemos un 201 después de un POST, el botón de retroceso del navegador se comporta mal.

Tenga en cuenta que las solicitudes de servicios web (que NO responden a un navegador) siguen completamente el estándar y NO redirigen después de la publicación.

Funciona así.

1. El navegador PUBLICA los datos.

2. Su aplicación valida los datos. Si no es válido, responda con el formulario para que puedan repararlo y POST.

3. Su aplicación responde con una redirección.

4. El navegador obtiene la redirección y hace un GET.

5. Su aplicación ve el GET y responde.

Ahora, hey presto! - el botón de retroceso funciona.

Answer 2

Para ser explícitos, los navegadores (incluidos los navegadores modernos como Firefox 3 e IE8) no "entienden la pista". y siga una respuesta HTTP 201: Creado con una solicitud GET al URI suministrado en el encabezado de ubicación.

Si desea que los navegadores vayan al URI suministrado en el encabezado de la ubicación, debe enviar un HTTP 303: ver Otro en su lugar.

Answer 3

Mi solución es responder con un '201 Creado' que contiene una página simple con un enlace al nuevo recurso, y una redirección de JavaScript usando location.replace ().

Esto permite que el mismo código funcione para las solicitudes de API y navegador, se reproduce bien con los botones Atrás y Actualizar y se degrada con gracia en los navegadores antiguos.

Answer 4

Como se indica en la especificación, la respuesta DEBE ser un HTTP 201 con redireccionamiento. Por lo tanto, no es obligatorio que un proveedor de navegador implemente la respuesta correcta ...

Debes intentar cambiar a un código 30x para ver si está correctamente redirigido. Si es así, es un problema del navegador, de lo contrario, puede provenir de su código (no sé nada en ASP.NET, así que no puedo "validar" su código)

Answer 5

¿No debería eso contar solo cuando algo es " Creado " y por lo tanto, ¿una simple redirección a la acción debería ser realmente suficiente?