Как работает опция Chrome «Запросить сайт рабочего стола»?

Question 1

Для iOS google chrome, когда пользователь нажимает кнопку «Запросить сайт для ПК», что браузер делает, чтобы попытаться открыть сайт для ПК? Я представляю какой-то заголовок на запрос, который ищут сайты, или что-то подобное?

Question 2

Думаю, разница только в User-Agent:заголовке в запросе.

Вот заголовки User-Agent, отправленные Chrome на моем устройстве 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

Обратите внимание на слово «Mobile» в первом, а также на упоминание системы и устройства Android. Проверяя их, я вижу, что они также предоставляют ложную информацию, а именно X11 и x86_64, чтобы точно соответствовать значению, отправляемому версией Desktop Linux. Хром.

Question 3

Просто хотел отметить, что Chrome теперь не только изменяет, User-Agentно и игнорирует исходный метатег области просмотра, если вы «Запросите сайт рабочего стола». Таким образом, больше не потребуется нюхать их User-Agent, и вы можете рассчитывать на изменение области просмотра, как это делают автоматически большинство отзывчивых сайтов. См. Это изменение для получения дополнительной информации.

Question 4

Еще одно небольшое отличие состоит в том, что запрос, похоже, был направлен на последний намеренно введенный URL до того, как его переместили какие-либо перенаправители. Например:

Дано: somesite.com обнюхивает агента, видит Android и делает document.location + = "/ m";

Затем: в браузере будет URL somesite.com/m

Но: если вы «Запросите настольный сайт», он изменит User-Agent и повторно запросит с somesite.com

Если только вы не вошли непосредственно по мобильному URL somesite.com/m, в этом случае он просто перезагружает somesite.com/m.

Я ожидал, что это работает с перенаправлениями HTTP 301 и 302, я знаю, что это работает с изменениями document.location (по крайней мере, как описано), и предполагал, что он работает с обновлениями <meta>.

Question 5

Этот фрагмент javascript будет делать то же самое:

function requestDesktopSite() {
    document.getElementsByTagName('meta')['viewport'].content='min-width: 980px;';
}

<button onclick="requestDesktopSite()">Request Desktop Site</button>

Развернуть фрагмент

Answer 1

Для iOS google chrome, когда пользователь нажимает кнопку «Запросить сайт для ПК», что браузер делает, чтобы попытаться открыть сайт для ПК? Я представляю какой-то заголовок на запрос, который ищут сайты, или что-то подобное?

Answer 2

64

Думаю, разница только в User-Agent:заголовке в запросе.

Вот заголовки User-Agent, отправленные Chrome на моем устройстве 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

Обратите внимание на слово «Mobile» в первом, а также на упоминание системы и устройства Android. Проверяя их, я вижу, что они также предоставляют ложную информацию, а именно X11 и x86_64, чтобы точно соответствовать значению, отправляемому версией Desktop Linux. Хром.

dsh
источник

14

Отдельный заголовок был бы великолепен. Обнюхивание пользовательского агента - это ужасно.

Mu Mind

10

Согласен. Иногда автоматическое обнаружение и перенаправление, осуществляемое некоторыми сайтами, крайне непродуктивно и неприятно.

dsh 06

5

Лучшим решением было бы определение размера устройства, интерфейсов и возможностей. Медиа-запросы CSS - это шаг в правильном направлении.

Брэд

1

Эта функция не реализуется простым переключением и обновлением UA. Дело в том, что большинство мобильных сайтов НЕ переключаются обратно на рабочий стол, если загружены с помощью строки UA рабочего стола. Значит, Safari использует ваш исходный запрос? Неа. Кажется, это работает, даже если вы изначально ввели URL-адрес мобильного сайта. Я не знаю, как это реализовано, потому что названия мобильных версий никоим образом не стандартизированы, но есть что-то более умное, чем простое изменение UA.

Эндрю Джи

Я хотел бы отметить, что «область просмотра макета» также изменится, если активировать опцию «Запросить сайт рабочего стола», которая влияет на медиа-запрос. Обратитесь к мобильному веб-справочнику для получения дополнительной информации о окне просмотра макета.

Рик

Answer 3

14

Отдельный заголовок был бы великолепен. Обнюхивание пользовательского агента - это ужасно.

Mu Mind

Answer 4

10

Согласен. Иногда автоматическое обнаружение и перенаправление, осуществляемое некоторыми сайтами, крайне непродуктивно и неприятно.

dsh 06

Answer 5

5

Лучшим решением было бы определение размера устройства, интерфейсов и возможностей. Медиа-запросы CSS - это шаг в правильном направлении.

Брэд

Answer 6

1

Эта функция не реализуется простым переключением и обновлением UA. Дело в том, что большинство мобильных сайтов НЕ переключаются обратно на рабочий стол, если загружены с помощью строки UA рабочего стола. Значит, Safari использует ваш исходный запрос? Неа. Кажется, это работает, даже если вы изначально ввели URL-адрес мобильного сайта. Я не знаю, как это реализовано, потому что названия мобильных версий никоим образом не стандартизированы, но есть что-то более умное, чем простое изменение UA.

Эндрю Джи

Answer 7

Я хотел бы отметить, что «область просмотра макета» также изменится, если активировать опцию «Запросить сайт рабочего стола», которая влияет на медиа-запрос. Обратитесь к мобильному веб-справочнику для получения дополнительной информации о окне просмотра макета.

Рик

Answer 8

Просто хотел отметить, что Chrome теперь не только изменяет, User-Agentно и игнорирует исходный метатег области просмотра, если вы «Запросите сайт рабочего стола». Таким образом, больше не потребуется нюхать их User-Agent, и вы можете рассчитывать на изменение области просмотра, как это делают автоматически большинство отзывчивых сайтов. См. Это изменение для получения дополнительной информации.

Answer 9

1

Спасибо за это. мой собственный очень простой веб-сайт ведет себя совсем иначе, когда на него не нажимают, и я не мог понять почему, поскольку я не делаю ничего, кроме медиа-запросов в CSS.

R

Answer 10

Еще одно небольшое отличие состоит в том, что запрос, похоже, был направлен на последний намеренно введенный URL до того, как его переместили какие-либо перенаправители. Например:

Дано: somesite.com обнюхивает агента, видит Android и делает document.location + = "/ m";

Затем: в браузере будет URL somesite.com/m

Но: если вы «Запросите настольный сайт», он изменит User-Agent и повторно запросит с somesite.com

Если только вы не вошли непосредственно по мобильному URL somesite.com/m, в этом случае он просто перезагружает somesite.com/m.

Я ожидал, что это работает с перенаправлениями HTTP 301 и 302, я знаю, что это работает с изменениями document.location (по крайней мере, как описано), и предполагал, что он работает с обновлениями <meta>.

Answer 11

Вы основали свой ответ на этом ?

Кил

Answer 12

@Keale, вероятно, наоборот, учитывая временные метки

verbumSapienti

Answer 13

Похоже, что если запрос POST получает 302 или 303, предлагающий GET для другого URL-адреса, тогда пользователь изменяет настройку `` представления рабочего стола '', браузер отправит запрос GET на исходный URL-адрес, который вернул 302/303 (теряя параметры POST ). Кажется, что и Firefox, и Chrome делают это, и ИМО, это определенно не то, что должно происходить.

Джейк

Answer 14

Этот фрагмент javascript будет делать то же самое:

function requestDesktopSite() {
    document.getElementsByTagName('meta')['viewport'].content='min-width: 980px;';
}

<button onclick="requestDesktopSite()">Request Desktop Site</button>

Развернуть фрагмент

Как работает опция Chrome «Запросить сайт рабочего стола»?

Ответы: