Comment fonctionne l'option "Demander un site de bureau" de Chrome?


94

Pour Google Chrome iOS, lorsqu'un utilisateur clique sur le bouton "Demander un site pour ordinateur", que fait le navigateur pour essayer d'afficher un site pour ordinateur? J'imagine une sorte d'en-tête sur la demande que les sites recherchent, ou quelque chose de similaire?

Réponses:


64

Je pense que la seule différence est l'en- User-Agent:tête de la demande.

Voici les en-têtes User-Agent envoyés par Chrome sur mon appareil Android:

Mozilla/5.0 (Linux; Android 4.0.4; Galaxy Nexus Build/IMM76K) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166 Mobile Safari/535.19

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.45 Safari/535.19

Notez le mot "Mobile" dans le premier, ainsi que la mention du système et de l'appareil Android. En vérifiant ces derniers, je vois qu'il fournit également de fausses informations - à savoir X11 et x86_64 - pour correspondre étroitement à la valeur envoyée par la version Desktop Linux de Chrome.


14
Un en-tête séparé serait génial. Le reniflement de l'agent utilisateur est si horrible.
Mu Mind

10
Je suis d'accord. Parfois, la détection et la redirection automatiques mises en œuvre par certains sites sont extrêmement contre-productives et aggravantes.
dsh

5
Une meilleure solution serait de détecter la taille, les interfaces et les capacités de l'appareil. Les requêtes multimédias CSS sont un pas dans la bonne direction.
Brad

1
Cette fonctionnalité n'est pas implémentée par un simple commutateur UA et une actualisation. La vérité est que la plupart des sites mobiles ne reviendront PAS au bureau s'ils sont chargés avec une chaîne UA de bureau. Alors Safari utilise votre demande d'origine? Nan. Cela semble fonctionner même si vous avez initialement tapé l'URL du site mobile. Je ne sais pas comment cela est mis en œuvre car le nom des versions mobiles n'est en aucun cas standardisé, mais il se passe quelque chose de plus intelligent qu'un simple changement d'UA.
Andrew G

Je tiens à souligner que la "fenêtre de présentation" changerait également si l'on déclenche l'option "Request Desktop Site", qui affecte la requête multimédia. Consultez le manuel Web mobile pour plus d'informations sur la fenêtre de présentation.
Rick

19

Je voulais juste souligner que Chrome modifie maintenant non seulement la User-Agentbalise Meta de la fenêtre d'affichage d'origine, mais ignore également la balise Meta d'origine si vous "Request Desktop Site". Ainsi, il ne sera plus nécessaire de renifler le User-Agentet vous pouvez compter sur le changement de la fenêtre d'affichage, comme la plupart des sites réactifs le feront automatiquement. Voir ce changement pour plus de références.


1
Merci pour ça. mon propre site Web très simple se comporte très différemment lorsqu'il n'est pas cliqué et je ne comprends pas pourquoi car je ne fais rien de plus que des requêtes multimédias en CSS.
R Reveley

17

Une autre légère différence est que la demande semble avoir été adressée à la dernière URL saisie intentionnellement avant que les directeurs ne la déplacent. Par exemple:

Étant donné: somesite.com renifle l'agent, voit Android et fait un document.location + = "/ m";

Ensuite: le navigateur aura une URL de somesite.com/m

Mais: si vous "demandez le site de bureau", cela changera l'agent utilisateur et la redemandera à partir de somesite.com

Sauf si: vous êtes entré directement sur l'URL mobile de somesite.com/m en premier lieu, auquel cas il ne fait que recharger somesite.com/m.

Je m'attendrais à ce que cela fonctionne avec les redirections HTTP 301 et 302, je sais que cela fonctionne avec les changements de document.location (au moins comme décrit), et je suppose que cela fonctionne avec les actualisations <meta>.


Avez-vous basé votre réponse sur cela ?
Keale

@Keale probablement l'inverse, étant donné les horodatages
verbumSapienti

On dirait que si une requête POST obtient un 302 ou 303 suggérant un GET pour une autre URL, alors l'utilisateur modifie le paramètre `` vue du bureau '', le navigateur soumettra une requête GET à l'URL d'origine qui a renvoyé le 302/303 (perdant les paramètres POST ). Il semble que Firefox et Chrome le font et IMO ce n'est certainement pas ce qui devrait se passer.
Jake

-2

Cet extrait de code javascript fera de même:

function requestDesktopSite() {
    document.getElementsByTagName('meta')['viewport'].content='min-width: 980px;';
}
<button onclick="requestDesktopSite()">Request Desktop Site</button>

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.