jquery-plugins descargar - jQuery $.ajax(), $.post enviando "OPCIONES" como REQUEST_METHOD en Firefox




cdn treeview (20)

Tener problemas con lo que pensé que era un plugin jQuery relativamente simple ...

El complemento debe obtener datos de un script php a través de ajax para agregar opciones a un <select> . La solicitud ajax es bastante genérica:

$.ajax({
  url: o.url,
  type: 'post',
  contentType: "application/x-www-form-urlencoded",
  data: '{"method":"getStates", "program":"EXPLORE"}',
  success: function (data, status) {
    console.log("Success!!");
    console.log(data);
    console.log(status);
  },
  error: function (xhr, desc, err) {
    console.log(xhr);
    console.log("Desc: " + desc + "\nErr:" + err);
  }
});

Esto parece funcionar bien en Safari. En Firefox 3.5, el REQUEST_TYPE en el servidor siempre es 'OPCIONES', y los datos de $ _POST no aparecen. Apache registra la solicitud como tipo 'OPCIONES':

::1 - - [08/Jul/2009:11:43:27 -0500] "OPTIONS sitecodes.php HTTP/1.1" 200 46

¿Por qué funcionaría esta llamada ajax en Safari, pero no en Firefox, y cómo lo arreglo para Firefox?

Response Headers
Date: Wed, 08 Jul 2009 21:22:17 GMT
Server:Apache/2.0.59 (Unix) PHP/5.2.6 DAV/2
X-Powered-By: PHP/5.2.6
Content-Length  46
Keep-Alive  timeout=15, max=100
Connection  Keep-Alive
Content-Type    text/html

Request Headers
Host    orderform:8888
User-Agent  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5
Accept  text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language en-us,en;q=0.5
Accept-Encoding gzip,deflate
Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive  300
Connection  keep-alive
Origin  http://ux.inetu.act.org
Access-Control-Request-Method   POST
Access-Control-Request-Headers  x-requested-with

Aquí hay una imagen de la salida de Firebug:


Answers

La solución a esto es:

  1. usar tipo de datos: json
  2. add &callback=? a tu url

Esto funcionó en llamar a la API de Facebook y con Firefox. Firebug utiliza GET lugar de OPTIONS con las condiciones anteriores (ambas).


Parece que si o.url = 'index.php' y este archivo existe, está bien y está devolviendo un mensaje de éxito en la consola. Devuelve un error si uso url: http://www.google.com

Si está haciendo una solicitud de publicación, ¿por qué no usar directamente el método $.post ?

$.post("test.php", { func: "getNameAndTime" },
    function(data){
        alert(data.name); // John
        console.log(data.time); //  2pm
    }, "json");

Es mucho más simple.


Utilicé el siguiente código en el lado de Django para interpretar la solicitud de OPCIONES y para establecer los encabezados de control de acceso requeridos. Después de esto, mis solicitudes de dominio cruzado de Firefox comenzaron a funcionar. Como se dijo antes, el navegador envía primero la solicitud de OPCIONES y luego, inmediatamente después, el POST / GET

def send_data(request):
    if request.method == "OPTIONS": 
        response = HttpResponse()
        response['Access-Control-Allow-Origin'] = '*'
        response['Access-Control-Allow-Methods'] = 'POST, GET, OPTIONS'
        response['Access-Control-Max-Age'] = 1000
        # note that '*' is not valid for Access-Control-Allow-Headers
        response['Access-Control-Allow-Headers'] = 'origin, x-csrftoken, content-type, accept'
        return response
    if request.method == "POST":
        # ... 

Edición: parece ser que al menos en algunos casos también debe agregar los mismos encabezados de control de acceso a la respuesta real. Esto puede ser un poco confuso, ya que la solicitud parece tener éxito, pero Firefox no pasa el contenido de la respuesta al Javascript.


Compruebe si la URL de action su formulario incluye la parte www del dominio, mientras que la página original que ha abierto se ve sin www .

Hecho típicamente para las URL canónicas.

Luché durante horas antes de encontrar este artículo y encontré el indicio de Cross Domain.


Otra posibilidad de evitar el problema es usar un script proxy. Ese método se describe por ejemplo aquí


¿Puedes probar esto sin

contentType:application/x-www-form-urlencoded


El motivo del error es la misma política de origen. Solo le permite hacer peticiones XMLHTTP a su propio dominio. Vea si puede usar una devolución de llamada JSONP lugar:

$.getJSON( 'http://<url>/api.php?callback=?', function ( data ) { alert ( data ); } );

Ya tengo este código manejando bien mi situación en PHP:

header( 'Access-Control-Allow-Origin: '.CMSConfig::ALLOW_DOMAIN );
header( 'Access-Control-Allow-Headers: '.CMSConfig::ALLOW_DOMAIN );
header( 'Access-Control-Allow-Credentials: true' );

Y funcionaba bien localmente y de forma remota, pero no para cargas cuando estaba remoto.

Algo sucedió con apache / php O mi código, no me molesté en buscarlo, cuando solicitas OPCIONES, devuelve mi encabezado con reglas de cors, pero con 302 resultados. Por lo tanto mi navegador no reconoce como una situación aceptable.

Lo que hice, basado en la respuesta de @Mark McDonald, es poner este código después de mi encabezado:

if( $_SERVER['REQUEST_METHOD'] === 'OPTIONS' )
{
    header("HTTP/1.1 202 Accepted");
    exit;
}

Ahora, al solicitar OPTIONS , simplemente enviará el encabezado y el resultado 202.


Tuvimos un problema como este con ASP.Net. Nuestro IIS estaba devolviendo un error interno del servidor al intentar ejecutar un jQuery $.post para obtener algún contenido html debido a PageHandlerFactory estaba restringido para responder solo los verbos GET,HEAD,POST,DEBUG . Así que puedes cambiar esa restricción agregando el verbo "OPCIONES" a la lista o seleccionando "Todos los verbos"

Puede modificar eso en su Administrador de IIS, seleccionando su sitio web, luego seleccionando Asignaciones de controladores, haciendo doble clic en su PageHandlerFactory para los archivos * .apx que necesite (utilizamos el grupo de aplicaciones integradas con Framework 4.0). Haga clic en Solicitar restricciones, luego vaya a Verbs Tabn y aplique su modificación.

Ahora nuestra solicitud de $.post está funcionando como se espera :)


Estaba buscando en la fuente 1.3.2, cuando uso JSONP, la solicitud se realiza mediante la creación de un elemento SCRIPT de forma dinámica, que supera la política del mismo dominio de los navegadores. Naturalmente, no puede realizar una solicitud POST utilizando un elemento SCRIPT, el navegador obtendría el resultado utilizando GET.

Cuando solicita una llamada JSONP, el elemento SCRIPT no se genera, porque solo hace esto cuando la llamada Tipo de AJAX se establece en GET.

http://dev.jquery.com/ticket/4690


Por favor tenga en cuenta:

JSONP solo admite el método de solicitud GET.

* Enviar solicitud por firefox : *

$.ajax({
   type: 'POST',//<<===
   contentType: 'application/json',
   url: url,
   dataType: "json"//<<=============
    ...
});

La solicitud anterior envía por OPCIONES (mientras ==> escribe: 'POST' ) !!!!

$.ajax({
    type: 'POST',//<<===
    contentType: 'application/json',
    url: url,
    dataType: "jsonp"//<<==============
    ...
});

Pero por encima de la solicitud de enviar por GET (mientras ==> tipo: 'POST' ) !!!!

Cuando se encuentre en "comunicación entre dominios", preste atención y tenga cuidado.


He solucionado este problema utilizando una solución basada totalmente en Apache. En mi vhost / htaccess pongo el siguiente bloque:

# enable cross domain access control
Header always set Access-Control-Allow-Origin "*"
Header always set Access-Control-Allow-Methods "POST, GET, OPTIONS"

# force apache to return 200 without executing my scripts
RewriteEngine On
RewriteCond %{REQUEST_METHOD} OPTIONS
RewriteRule .* / [R=200,L]

Es posible que no necesite la última parte, dependiendo de lo que suceda cuando Apache ejecute su secuencia de comandos de destino. El crédito va a la gente amigable de ServerFault para la última parte.


Este PHP en la parte superior de la secuencia de comandos de respuesta parece funcionar. (Con Firefox 3.6.11. Aún no he realizado muchas pruebas).

header('Access-Control-Allow-Origin: *');
header('Access-Control-Allow-Methods: POST, GET, OPTIONS');
header('Access-Control-Max-Age: 1000');
if(array_key_exists('HTTP_ACCESS_CONTROL_REQUEST_HEADERS', $_SERVER)) {
    header('Access-Control-Allow-Headers: '
           . $_SERVER['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']);
} else {
    header('Access-Control-Allow-Headers: *');
}

if("OPTIONS" == $_SERVER['REQUEST_METHOD']) {
    exit(0);
}

Necesitas hacer algún trabajo en el lado del servidor. Veo que está utilizando PHP en el lado del servidor, pero la solución para la aplicación web .NET está aquí: No se puede establecer el tipo de contenido en 'application / json' en jQuery.ajax

Haga lo mismo en el script PHP y funcionará. Simplemente: en la primera solicitud, el navegador pregunta al servidor si está autorizado para enviar dichos datos con ese tipo y la segunda solicitud es la correcta / permitida.


Utilicé una URL de proxy para resolver un problema similar cuando deseo publicar datos en mi apache solr alojado en otro servidor. (Puede que esta no sea la respuesta perfecta, pero resuelve mi problema).

Siga esta URL: usando Mode-Rewrite para proxy , agrego esta línea a mi httpd.conf:

 RewriteRule ^solr/(.*)$ http://ip:8983/solr$1 [P]

Por lo tanto, solo puedo publicar datos en / solr en lugar de publicar datos en http://ip:8983/solr/ *. Entonces se publicarán los datos en el mismo origen.


El culpable es la solicitud de verificación previa mediante el método OPCIONES

Para los métodos de solicitud HTTP que pueden causar efectos secundarios en los datos del usuario (en particular, para los métodos HTTP que no sean GET, o para el uso de POST con ciertos tipos MIME), la especificación exige que los navegadores "revisen" la solicitud, solicitando métodos compatibles de servidor con un método de solicitud de OPCIONES HTTP, y luego, tras la "aprobación" del servidor, envía la solicitud real con el método de solicitud HTTP real.

Las especificaciones web se refieren a: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS

Resolví el problema agregando las siguientes líneas en Nginx conf.

    location / {
               if ($request_method = OPTIONS ) {
                   add_header Access-Control-Allow-Origin  "*";
                   add_header Access-Control-Allow-Methods "POST, GET, PUT, UPDATE, DELETE, OPTIONS";
                   add_header Access-Control-Allow-Headers "Authorization";
                   add_header Access-Control-Allow-Credentials  "true";
                   add_header Content-Length 0;
                   add_header Content-Type text/plain;
                   return 200;
               }
    location ~ ^/(xxxx)$ {
                if ($request_method = OPTIONS) {
                    rewrite ^(.*)$ / last;
                }
    }

Intenta agregar la opción:

tipo de datos: "json"



Tuve un problema similar al intentar usar la API de Facebook.

El único tipo de contenido que no envió la solicitud de verificación previa parecía ser solo texto / sin formato ... no el resto de los parámetros mencionados here en Mozilla

  • ¿Por qué es este el único navegador que hace esto?
  • ¿Por qué Facebook no conoce y acepta la solicitud de verificación previa?

FYI: El documento de Moz mencionado anteriormente sugiere que los encabezados X-Lori deberían activar una solicitud de verificación previa ... no lo hace.


Puede poner la configuración Ajax de jQuery en modo síncrono llamando

jQuery.ajaxSetup({async:false});

Y luego realice sus llamadas Ajax usando jQuery.get( ... );

Luego solo enciéndelo de nuevo una vez

jQuery.ajaxSetup({async:true});

Supongo que funciona de la misma manera sugerida por @Adam, pero podría ser útil para alguien que quiere reconfigurar su jQuery.get() o jQuery.post() para la sintaxis más elaborada de jQuery.ajax() .





ajax firefox jquery-plugins jquery