asp.net mvc - route - ¿Cuál es la respuesta correcta a una solicitud HTTP POST?

web forms c# tutorial

Question

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

Si se ha creado un recurso en el servidor de origen, la respuesta DEBERÍA ser 201 (Creado) y contener una entidad que describa el estado de la solicitud y haga referencia al nuevo recurso, y un encabezado de Ubicación (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 en realidad parece ser enviar un redireccionamiento al recurso recién creado.

Estoy construyendo mi sitio con ASP.NET MVC e intenté seguir las especificaciones, 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 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 redireccionar al nuevo recurso. ¿He cometido un error generando la respuesta correcta, o los navegadores web no esperan este tipo de respuesta, sino que dependen de los servidores para enviar una respuesta de redireccionamiento?

Answer 1

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

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

Answer 2

Redirigir después de publicar o publicar / redirigir / obtener es algo que su aplicación debe hacer para ser 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 una 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 lo puedan arreglar y POST.

3. Su aplicación responde con un redireccionamiento.

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

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

Ahora - ¡listo! - el botón Atrás funciona.

Answer 3

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

Si desea que los navegadores vayan al URI proporcionado en el encabezado de Ubicación, debe enviar un HTTP 303: See Other estado en su lugar.

Answer 4

¿No debería eso solo contar para cuando algo está "Creado" y por lo tanto un simple redireccionamiento a la acción debería ser genuinamente suficiente?

Answer 5

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 API y solicitudes de navegador, se juega muy bien con los botones Atrás y Actualizar y se degrada graciosamente en navegadores antiguos.