Notes |
|
|
PS: карта мелкая (но с привязкой), если кто искать будет - то вот: http://secure.parksandresorts.wdpromedia.com/media/maps/prod/v6/tiles/11/559/855.jpg |
|
|
|
Мог бы и посмотреть сниффером в чем разница в запросе и ответе. |
|
|
|
Мог бы, но это займет время. Загруз полнейший уже неск.месяцев как...:( Может у кого из разрабов быстрее получится, или при взгляде в сорц качалки опытным взглядом - оно и так найдется... |
|
|
|
У меня идей нету, как и лишнего времени. За остальных не скажу. |
|
|
(0010710)
|
Garl
|
01-03-2013 04:25
|
|
GetUrlScript.txt :
begin
ResultURL:=GetURLBase+inttostr(GetZ-1)+'/'+inttostr(GetX)+'/'+inttostr(GetY)+'.jpg';
RequestHead:=
'User-Agent: Opera/9.80 (Windows NT 6.1; MRA 5.10 (build 5231)) Presto/2.12.388 Version/12.14' + 0000013#10 +
'Host: secure.parksandresorts.wdpromedia.com' + 0000013#10 +
'Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/webp, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1' + 0000013#10 +
'Accept-Language: ru-RU,ru;q=0.9,en;q=0.8';
end.
и готово |
|
|
|
>и готово
Не, ну это понятно, что при принудительном указании верных хидеров ручками - всё работает.
непонятно, почему в предыдущей версии САСа всё работает с установками по умолчанию (читай: хидеры отправляются верные сугубо самостоятельно), а в новой - они отправляются корявыми, причем не в каждый запрос - а как-то рандомно.
Просто предлагаю починить ночнушку так, чтобы оно само слало нормальные хидеры по умолчанию. Может там строка не закрыта где, или еще какая мелочь...а не просто скачать именно эту карту через прямое указание нужного ручками. Если ночнушка где-то тупит с хидерами - то она будет тупить и доставлять проблем далеко не только на этой карте, я так думаю. Всего лишь дождаться очередного щепетильного сервера, который не прощает - и оно ж опять вылезет... :)
Посмотрю снифферомв чем там проблема, как только доберусь до оного. |
|
|
(0010712)
|
zed
|
01-03-2013 05:37
|
|
406 Not Acceptable — запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.
По дефолту, САС отправляет: "Accept: image/jpg", и раз сервер возвращает 406, то возможно местами у них там не jpeg, а что-то ещё и по цитате выше - в теле ответа должна быть правильная строка Accept.
>чтобы оно само слало нормальные хидеры по умолчанию
оно шлёт нормальные хидеры, а то, что этот zmp работал на старой версии - чисто случайность |
|
|
|
>то возможно местами у них там не jpeg, а что-то ещё
Старой версией качается ТОЛЬКО жпег. Карта при этом получается без дырок, так что все приходящие тайлы таки проходят указанный в ЗМП "Content-type:" в старой версии САСа.
При этом, если подольше подолбиться в 406йеррор ручками через "Загрузить тайл основной карты" раз так 20 - то он в конце концов прогружается и в новой версии тоже, и он прогружается именно как жпег. Если бы была тема "У них там не везде жпег" - то тайл бы так и не приходил бы без соответствующего изменения ЗМП, хоть задолбись в него.
>и по цитате выше - в теле ответа должна быть правильная строка Accept.
Возможно, что она там и есть - надо смотреть сниффером.
А вот использует ли САС то, во что его возможно тыкает носом сервер - уже вопрос к разрабам.
>то, что этот zmp работал на старой версии - чисто случайность
Предлагаю повторить и закрепить эту случайность в текущих ночнушках.
Нет, не для того чтобы скачать именно эту карту (я ее уже давно выкачал старой версией), а для того чтобы не глючило в будущем.
Но до сниффера все равно доберусь. Самому интересно стало, в чем же там разница... :) |
|
|
(0010716)
|
Parasite
|
01-03-2013 06:59
(edited on: 01-03-2013 07:01) |
|
Таки просниффил:
Старая версия - всё грузится:
===================
GET http://secure.parksandresorts.wdpromedia.com/media/maps/prod/v6/tiles/20/286188/437988.jpg HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)
Host: secure.parksandresorts.wdpromedia.com
Pragma: no-cache
Accept-Encoding: gzip, deflate
HTTP/1.0 200 OK
Content-Length: 1654
Content-Type: image/jpeg
Last-Modified: Thu, 22 Nov 2012 06:15:51 GMT
Accept-Ranges: bytes
ETag: "67d326d278c8cd1:c64"
Server: ATS/3.2.0
X-Powered-By: ASP.NET
Access-Control-Allow-Origin: *
Cache-Control: public, max-age=86385
Expires: Sat, 02 Mar 2013 06:40:44 GMT
Date: Fri, 01 Mar 2013 06:40:59 GMT
Proxy-Connection: close
......JFIF.............C.................................................
===================
Ночнушка - 406:
===================
GET http://secure.parksandresorts.wdpromedia.com/media/maps/prod/v6/tiles/20/286188/437988.jpg HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)
Accept: image/jpeg
Host: secure.parksandresorts.wdpromedia.com
Connection: Keep-Alive
Pragma: no-cache
Accept-Encoding: gzip, deflate
HTTP/1.0 406 Not Acceptable
Content-Length: 982
Content-Type: text/html
Server: ATS/3.2.0
X-Powered-By: ASP.NET
Access-Control-Allow-Origin: *
Content-Encoding: gzip
Date: Fri, 01 Mar 2013 06:47:43 GMT
Vary: Accept-Encoding
X-N: S
Proxy-Connection: close
===================
Из разницы - вижу посылаемое ночнушкой (но не посылаемое старой версией) "Accept: image/jpeg", а также "Connection: Keep-Alive". А еще там gzip - возможно что и оттуда ноги растут...
|
|
|
|
Если указано
Accept-Encoding: gzip, deflate
то указывать
Accept: image/jpeg
вообще-то никак нельзя. Надо звёздочки пихать. |
|
|
(0010723)
|
Parasite
|
01-03-2013 08:08
(edited on: 01-03-2013 08:12) |
|
Имхо вообще передавать конкретный "Accept" с нашей стороны - не особо нужно. Иначе получается картина "ДО запроса ты уже обязан знать, в каком виде ВСЕГДА будут ответы сервера на этот запрос" - а иначе тот не разберется что и как отдать, если не сумеет отдать нужное в запрошенном виде. Что, скорей всего, в нашем случае и имеет место быть.
Да и дебажить новые карты сложнее ж.
А езе и с Keep-Alive могут быть грабли. Возможно, сервер просто SOCKET_REUSE не умеет или не хочет, а от него настырно хотят именно этого. Отсюда наверное растет и факт того, что если подольше подолбиться - тайл таки скачается (сервер таки закроет Keep-Alive сокет в какое-то время, и создаст новый с нуля в ответ на очередной запрос?).
|
|
|
(0010725)
|
vasketsov
|
01-03-2013 08:14
(edited on: 01-03-2013 08:17) |
|
В "нашем случае имеет место быть" банальная "случайность": серваку говорят что надо преимущественно гзип но можно и жпег, но примем мы только жпег. Ну вот он и говорит что вы ребята офигели, кидается какашками в том случае, если посчитает целесообразным вернуть гзип. Работает только если он посчитает целесообразным вернуть жпег не ужимая.
>с Keep-Alive могут быть грабли
Вероятность этого 100%-99.(9)%. При тех же настройках через прокси (со своим KA и далее по цепочке) пример от Garl-а выше (где есть волшебные звёздочки */*) будет работать.
|
|
|
|
>Ну вот он и говорит что вы ребята офигели, кидается какашками в том случае, если посчитает целесообразным вернуть гзип. Работает только если он посчитает целесообразным вернуть жпег не ужимая.
Какая-то весьма изощренная логика на, повторюсь, ОДНОМ И ТОМ ЖЕ тайле. Я так понимаю, что при прочих равных - он его должен ЛИБО всегда отдавать, ЛИБО всегда нет если сервер что-то не устраивает. Алгоритм-то отдачи контента на его стороне фиксирован на 99.9% вероятности, скорее всего. У нас в ZMP - тоже. А результкт, как у того Троцкого - то туда, то сюда, то отдамся, то не отдамся, то отдамся только после долгой долбежки вокруг и около...
>При тех же настройках через прокси (со своим KA и далее по цепочке) пример от Garl-а выше (где есть волшебные звёздочки */*) будет работать.
Это-то понятно. Мы просто перекрываем свой баг (или фичу?) ручками - и оно скорее всего заработает. Именно в этом случае. Но бага\фичи-то не отменяет. Оный я и предлагаю полечить - чтобы работало по дефолту. Проблема-то не в сервере, коль старой версии всё отдает ОК, да и браузеру - тоже.
Путь скачки именно этой карты в данном тикете мне не нужен - она уже выкачана, вариантов лечения именно этой карты - тут не требуется. Предлагается разобраться, почему конкретно глючит именно дефолтный вариант хидеров - и полечить, засим всё. То есть, ввести те самые Garl'овы звездочки в дефолтный набор хидеров САСа (если с гзипом надо передавать именно звездочки), либо убрать Accept\gzip, или еще как. Просто чтобы этот вопрос больше не всплывал и на других возможных картах, и хомяки не ломали голову еще раз. |
|
|
|
>Какая-то весьма изощренная логика на, повторюсь, ОДНОМ И ТОМ ЖЕ тайле.
То что тайл один и тот же - роли не играет, так как в приведённом варианте решение загзиповать или нет тайл принимается исключительно сервером по одному ему ведомым основаниям (например по занятости рабочих потоков для гзипования).
Как пример - на заре переделки формы поиска доступных снимков была ровно эта же проблема для нокии. Причём на одном и том же тайле (там выдирается exif из тайла) то работает, то нет (но на 3-4 раз сработает). Идея что сервер вот так вот халтурит подтвердилась на 100%. Он не обязан отдавать гзип или не гзип, и может вернуть что угодно. Когда я писал парсер для росреестра - я опять забыл об этом и опять налетел на ровно то же самое.
>Но бага\фичи-то не отменяет
Ещё раз: весь баг (это не фича, я гарантирую это) в том, что при указании Accept-Encoding: gzip указали только image/jpeg. Надо указывать просто */* (или добавлять */* в конец списка Accept). Разумеется он (этот баг) к конкретной карте не относится.
>либо убрать Accept\gzip
Очевидно это не вариант. Начиная от бана сервера в отношении неумеющих разжимать клиентов, и кончая банальным дцатикратным увеличением трафика. Если подумать - Accept-Encoding: gzip, deflate в идеале вообще должен быт всегда, как и добавление волшебных звёздочек в Accept. Броузеры именно так и делают, к слову, допуская сжатие контента. |
|
|
|
>Начиная от бана сервера в отношении неумеющих разжимать клиентов
Вроде как пока еще нет такого стандарта, чтобы любой отдельно взятый клиент либо безусловно умел разгзиповывать - либо Васю на мороз. Так что официальных поводов для бана таки не вижу. Не, ну понятно что на каждом сервере можно извратиться и накрутить какой угодно отсебятины - но банить за отсутствие умения гзипа это имхо перебор. Мне такие дикие ресурсы не попадались пока еще.
>кончая банальным дцатикратным увеличением трафика.
Ну не на жпегах же. :)
Данный сервер, насколько я понимаю - чистый CDN, и гзипить там разве что хидеры от тех жпегов... а вебморда и прочие стили\явы лежат на более другом disney.com. Впрочем, это детали конкретно этого ресурса конечно же.
>Если подумать - Accept-Encoding: gzip, deflate в идеале вообще должен быт всегда
А я бы предложил наоборот: в дефолтовых САСовых хидерах оставить только самый минимальный минимум (GET/POST/HTTP, URL, Content-Length и прочий минимальный джентльменский набор), а все что свыше (включая гзиповку, управление кэшированием и прочие звездочки) - предложил бы вынести в ZMP именно тех карт, где это действительно нужно. Вот например на обсуждаемой карте - нет никаких экономических причин юзать гзип, так и зачем передавать его хидер серверу? Этот хидер скорее всего длиннее, чем экономия от гзипа.... Короче, предложил бы ограничиться минимально разумной достаточностью вшитой в САС, а все что может понадобиться конкретному юзеру свыше - высунуть наружу, в ЗМП.
В этом случае, например, будет возможность отключить ненужное\глючашее сугубо силами хомяка, а не разработчика САСа. Например, отключить ненужный+глючащий на этой вот карте гзип я сейчас не смогу, а был бы он вынесен в ЗМП - то дело было бы в паре закомментированных строк, не теряя своего и вашего времени на этот вот тикет.
>весь баг (это не фича, я гарантирую это)
Что и требовалось доказать. Собссно, и вот. Чините-сс. :) |
|
|
(0010730)
|
zed
|
01-03-2013 10:45
|
|
Странно, но у меня вот такие хидеры:
(Request-Line):GET /media/maps/prod/v6/tiles/6/36/18.jpg HTTP/1.1
User-Agent:Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727)
Accept:image/jpg
Host:secure.parksandresorts.wdpromedia.com
Connection:Keep-Alive
Cache-Control:no-cache
И никаких gzip-ов нету. Полностью удалить строку Accept из запроса не представляется возможным, но добавить в конец */* можно легко. |
|
|
(0010731)
|
zed
|
01-03-2013 10:48
|
|
Подозреваю, что тут влияют настройки IE. |
|
|
|
>Подозреваю, что тут влияют настройки IE.
При этом в самом ИЕ - вся карта (через свою вебморду) работает? Не, не в нем дело скорей всего.
Впрочем, пробуй: http://disneyworld.disney.go.com/maps/ (ох щщи - она саму себя еще и на HTTPS форвардит как оказывается, и далее так и с него и работает...Впрочем, только что попробовал тайлы по HTTPS - в новом сасе проблема и еррор ровно те же).
>Полностью удалить строку Accept из запроса не представляется возможным, но добавить в конец */* можно легко.
А попробуй сбилдить и выложить? Я потестю, если ОК - то в этом и проблема.
И еще сбилдить с Connection: Close вместо Keep-Alive тоже.
PS: потестить смогу не раньше понедельника. Не горит, собссно... |
|
|
(0010734)
|
zed
|
01-03-2013 11:26
|
|
>При этом в самом ИЕ - вся карта (через свою вебморду) работает? Не, не в нем дело скорей всего.
Я о строке "Accept-Encoding: gzip, deflate" - её наличие определяется скорее всего настройками IE. И когда эти настройки "не в тему" добавляются к нашим хидерам и получаем то что имеем. |
|
|
(0010735)
|
vasketsov
|
01-03-2013 11:26
(edited on: 01-03-2013 11:28) |
|
>но банить за отсутствие умения гзипа это имхо перебор
Не более перебористее нежели по UserAgent-у или кукам (которые отключабельные).
>нет никаких экономических причин юзать гзип
Как бы да, но покуда пути картосерверов неисповедимы, задача прикидываться броузером может быть более важна, нежели экономия на строке в заголовке. Впрочем согласен, что в крайнем случае это можно в скрипте указать.
>Подозреваю, что тут влияют настройки IE
Возможно Parasite пропихивает запрос через прокси, и там натягивается gzip.
>добавить в конец */* можно легко
Есть подозрение, что это всех устроит, включая прокси-серверы и прочие картосерверы. Хотя пока что непонятно, почему вообще не указывать всегда только */* и разбирать тип контента уже имея ответ на руках. Есть какая-то алгоритмическая проблема указать */* во всех случаях, кроме прямого указания в хедере в скрипте чего надо пользователю?
>И еще сбилдить с Connection: Close вместо Keep-Alive тоже
Это заведомо лишнее.
|
|
|
|
>её наличие определяется скорее всего настройками IE. И когда эти настройки "не в тему" добавляются к нашим хидерам и получаем то что имеем.
Тогда это какие-то весьма хитрые настройки IE, что добавляются и глючат исключительно к этой ночнушке и только на этой карте (причем не всегда, а в Trotsky-style), а штук 20 работающих на этой же машине в фоне САСов разных версий и степеней озадаченности разнообразными серверами - качают себе (при тех же настройках IE) и в ус не дуют. Уж скорее допущу что это локальный Сквид балуется - но опять же, через него идет всё и вся, и до сего момента ни единой проблемы с этим не было.
>Возможно Parasite пропихивает запрос через прокси, и там натягивается gzip.
Именно. Но про принудительный гзип там - не помню. Если и включал когда - то это было весьма давно, и проблем ни разу ни на одном ресурсе не доставляло.
>Это заведомо лишнее.
Сугубо проверки для. Был небольшой экспириенс, когда именно из-за невнятного проксифицирования этого вкупе с HTTP1.1 - была кучка малообъяснимых глюков. Zed должен это тоже помнить, собссно - с ним и решали. Благо что сбилдить с этой строчкой - как 2 пальца о консоль, а проверить - не повредит, и много времени не займет. |
|
|
(0010740)
|
zed
|
01-03-2013 13:35
|
|
>Есть какая-то алгоритмическая проблема указать */*
Как раз наоборот, клиент (Alcinoe) сам всегда подставляет */* если не находит Accept в юзерских заголовках. |
|
|
|
>клиент (Alcinoe) сам всегда подставляет */* если не находит Accept в юзерских заголовках
Именно такое поведение и хотелось бы поиметь в итоге |
|
|
|
|
|
|
|
|
(0013761)
|
zed
|
11-02-2014 19:07
|
|
Пришли к тому, что предлагают заменить Accept:image/jpg на Accept:*/* всегда и везде, если юзер не указал иного сам через хидеры. Сейчас же в Accept мы подставляем ContentType из zmp. |
|
|
|
Ну так что тебя останавливает в реализации? |
|
|
(0013763)
|
zed
|
12-02-2014 04:20
|
|
|
|
|
> А тебя?
Ну хотя бы то, что это ты добавлял много лет назад
https://bitbucket.org/sas_team/sas.planet.src/commits/c8d2b26d3dcba992839f97bd5c49af57d31a3064
И я понятия не имею для чего и какие карты отвалятся если убрать эту подстановку. |
|
|
(0013765)
|
zed
|
12-02-2014 16:58
|
|
Я это добавлял не для карт, а потому что новый компонент всегда отсылает поле Accept и были грабли с его инициализацией (баг 0001026). А конкретный ContentType я подставил тогда "за компанию" и ты даже занёс чего-то там в ToDo относительно него. Мне казалось что не помешает уведомить сервер о ожидаемом типе и я без понятия отвалятся ли какие-нибудь карты если это убрать. |
|
|
|
Нее. До того коммита инициализация FHttpClient.RequestHeader.Accept := '*/*' уже была. Ты ее почему-то заменил. В общем что хочешь, то и делай с этим багом. |
|
|
(0013767)
|
zed
|
12-02-2014 17:22
|
|
> Ты ее почему-то заменил.
Я ж говорю - за компанию. А то, что это не за один коммит прилетело - не суть. Это всё было к тому же в тестовой ветке Threaded - основная цель доработки там было прикрутить многопоточную качалку вместо однопоточной.
> В общем что хочешь, то и делай с этим багом
А шоб я ещё знал, что с ним делать, уже б давно сделал. Там это за пять минут делается: что оторвать, что добавить - одинаково легко и быстро. |
|
|
(0013768)
|
zed
|
12-02-2014 17:30
|
|
Да и что там с тем ToDo? Что ты там имел в виду? |
|
|
|
В TODO я подразумевал, что нужно в параметры zmp добавить отдельное поле Accept.
>А шоб я ещё знал, что с ним делать, уже б давно сделал. Там это за пять минут делается: что оторвать, что добавить - одинаково легко и быстро.
Я тоже не знаю. Делай по своему усмотрению. |
|