it-swarm.com.de

Unterschied zwischen AJAX Anfrage und eine regelmäßige Browseranfrage

Gibt es einen Unterschied zwischen einer AJAX- Anforderung und einer direkten Browseranforderung (in Bezug auf das Aufrufen und Laden einer Webseite)?

Mit anderen Worten, ich meine: Wird eine direkte serverseitige Anforderung anders behandelt als eine clientseitige Anforderung (vom Browser initiiert)?

31
Qqwy

Eine AJAX -Anforderung ist identisch mit einer "normalen" Browseranforderung, soweit der Server betroffen ist, anders als möglicherweise geringfügig abweichende HTTP-Header. z.B. Chrom sendet:

X-Requested-With:XMLHttpRequest

Ich bin nicht sicher, ob der Header standardisiert ist oder nicht, oder ob er in jedem Browser anders ist oder sogar überhaupt in jedem Browser.


edit: Ich nehme das zurück, der Header wird von jQuery (und wahrscheinlich auch anderen JS-Bibliotheken) gesendet, nicht vom Browser, wie von:

var xhr = new XMLHttpRequest();
xhr.open('GET', '/');
xhr.send();

was sendet:

Accept:*/*
Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Connection:keep-alive
Cookie: ....
Host:stackoverflow.com
If-Modified-Since:Sat, 31 Dec 2011 01:57:24 GMT
Referer:http://stackoverflow.com/questions/8685750/how-does-an-ajax-request-differ-from-a-normal-browser-request/8685758
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_7) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.12 Safari/535.11

das führt mich zu dem Schluss, dass standardmäßig es absolut keinen Unterschied gibt.

24
Mark Kahn

Es kann einige Headerunterschiede geben, der Hauptverhaltensunterschied liegt jedoch auf dem Client. 

Wenn der Browser wie in window.location.href = "index.html" eine regelmäßige Anforderung abruft, wird das aktuelle Fenster gelöscht und die Serverantwort in das Fenster geladen.

Bei einer Ajax-Anforderung ist das aktuelle Fenster/Dokument nicht betroffen, und der JavaScript-Code kann die Ergebnisse der Anforderung untersuchen und mit diesen Ergebnissen tun, was sie will (HTML-Code dynamisch in die Seite einfügen, JSON analysieren und die Seitenlogik verwenden, XML analysieren , usw...).

Der Server macht nichts anderes - nur, wie der Client die Antwort der beiden Anforderungen behandelt.

28
jfriend00

Einige populäre clientseitige Bibliotheken wie jQuery enthalten den X-Requested-With-Header in ihren Anforderungen und setzen ihn auf XMLHttpRequest, um sie als AJAX zu markieren. 

Dies scheint vor einigen Jahren als Standard zu gelten (wahrscheinlich aufgrund der großen Beliebtheit von jQuery und seiner Präsenz auf fast jeder Website), dass viele serverseitige Frameworks sogar Helfer haben, die sich um die Suche nach diesem Header in der erhaltenen Anfrage kümmern für dich:

ASP.NET MVC 5:

HttpRequestBase.IsAjaxRequest()

Django:

HttpRequest.is_ajax()

Flasche:

flask.Request.is_xhr

Es scheint jedoch, dass mit dem Ende von jQuery in der Frontend-Welt und der Standardisierung der fetch-API und dem Aufkommen anderer moderner clientseitiger Bibliotheken, die standardmäßig keinen Header für diesen Zweck hinzufügen, das Muster gefallen ist in die Obsoleszenz auch im Backend; mit ASP.NET MVC ohne Helfer in neueren Versionen und Flask, der es als veraltet markiert.

0
slashCoder

Nicht wirklich. Die meisten Ajax-Clients senden jedoch ein X-Requested-With=XMLHttpRequest HTTP-Header

0
Juan Mendes

Obwohl ich glaube, dass es Leute gibt, gibt es in Weblogic etwas völlig Ungewöhnliches: Ich schreibe eine App mit dem ExtJS-Framework, das AJAX-Aufrufe durchführt.

Beim Ausführen von j_security_check erhalte ich immer Fehler, wenn dies auf AJAX Weise gemacht wird: Weblogic sagt: 

unauthorized: var submitButton = new Ext.Button({
            text: 'Logon',
            formBind: true, //only enabled once the form is valid
            disabled: true,
            handler: function() {                
                Ext.Ajax.request({
                    url: "j_security_check",
                    params: {
                        j_username: dlg.getForm().findField('j_username').getValue(),
                        j_password: dlg.getForm().findField('j_password').getValue()
                    },
                    method: "GET"
                });
            }
        });

Das schlägt fehl.

Wenn ich das ausstelle: 

window.location.href = "j_security_check?j_username=" + dlg.getForm().findField('j_username').getValue() + "&j_password=" + dlg.getForm().findField('j_password').getValue();

Es klappt! Seltsam.

0
Lawrence

Ich überprüfe immer, ob "text/html" der "beste" Accept-Mimetyp der Anfrage ist, da Browser diesen immer als ersten senden.

Firefox-Beispiel:

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

Natürlich kann dies immer noch eine Ajax-Anforderung mit text/html als Accept-Mimetyp sein, aber ich fand dies zuverlässig, wenn Sie wissen, welcher Client Ihre Backend-API verbraucht.