0001832: HTTP: Error 406 Not acceptable

Notes
(0010635) Parasite (administrator) 25-02-2013 08:48	PS: карта мелкая (но с привязкой), если кто искать будет - то вот: http://secure.parksandresorts.wdpromedia.com/media/maps/prod/v6/tiles/11/559/855.jpg

(0010703) vdemidov (manager) 28-02-2013 17:39	Мог бы и посмотреть сниффером в чем разница в запросе и ответе.

(0010705) Parasite (administrator) 28-02-2013 18:06	Мог бы, но это займет время. Загруз полнейший уже неск.месяцев как...:( Может у кого из разрабов быстрее получится, или при взгляде в сорц качалки опытным взглядом - оно и так найдется...

(0010707) vdemidov (manager) 28-02-2013 19:31	У меня идей нету, как и лишнего времени. За остальных не скажу.

(0010710) Garl (manager) 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. и готово

(0010711) Parasite (administrator) 01-03-2013 05:03	>и готово Не, ну это понятно, что при принудительном указании верных хидеров ручками - всё работает. непонятно, почему в предыдущей версии САСа всё работает с установками по умолчанию (читай: хидеры отправляются верные сугубо самостоятельно), а в новой - они отправляются корявыми, причем не в каждый запрос - а как-то рандомно. Просто предлагаю починить ночнушку так, чтобы оно само слало нормальные хидеры по умолчанию. Может там строка не закрыта где, или еще какая мелочь...а не просто скачать именно эту карту через прямое указание нужного ручками. Если ночнушка где-то тупит с хидерами - то она будет тупить и доставлять проблем далеко не только на этой карте, я так думаю. Всего лишь дождаться очередного щепетильного сервера, который не прощает - и оно ж опять вылезет... :) Посмотрю снифферомв чем там проблема, как только доберусь до оного.

(0010712) zed (manager) 01-03-2013 05:37	406 Not Acceptable — запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1. По дефолту, САС отправляет: "Accept: image/jpg", и раз сервер возвращает 406, то возможно местами у них там не jpeg, а что-то ещё и по цитате выше - в теле ответа должна быть правильная строка Accept. >чтобы оно само слало нормальные хидеры по умолчанию оно шлёт нормальные хидеры, а то, что этот zmp работал на старой версии - чисто случайность

(0010715) Parasite (administrator) 01-03-2013 06:32	>то возможно местами у них там не jpeg, а что-то ещё Старой версией качается ТОЛЬКО жпег. Карта при этом получается без дырок, так что все приходящие тайлы таки проходят указанный в ЗМП "Content-type:" в старой версии САСа. При этом, если подольше подолбиться в 406йеррор ручками через "Загрузить тайл основной карты" раз так 20 - то он в конце концов прогружается и в новой версии тоже, и он прогружается именно как жпег. Если бы была тема "У них там не везде жпег" - то тайл бы так и не приходил бы без соответствующего изменения ЗМП, хоть задолбись в него. >и по цитате выше - в теле ответа должна быть правильная строка Accept. Возможно, что она там и есть - надо смотреть сниффером. А вот использует ли САС то, во что его возможно тыкает носом сервер - уже вопрос к разрабам. >то, что этот zmp работал на старой версии - чисто случайность Предлагаю повторить и закрепить эту случайность в текущих ночнушках. Нет, не для того чтобы скачать именно эту карту (я ее уже давно выкачал старой версией), а для того чтобы не глючило в будущем. Но до сниффера все равно доберусь. Самому интересно стало, в чем же там разница... :)

(0010716) Parasite (administrator) 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 - возможно что и оттуда ноги растут...

(0010722) vasketsov (manager) 01-03-2013 08:00	Если указано Accept-Encoding: gzip, deflate то указывать Accept: image/jpeg вообще-то никак нельзя. Надо звёздочки пихать.

(0010723) Parasite (administrator) 01-03-2013 08:08 edited on: 01-03-2013 08:12	Имхо вообще передавать конкретный "Accept" с нашей стороны - не особо нужно. Иначе получается картина "ДО запроса ты уже обязан знать, в каком виде ВСЕГДА будут ответы сервера на этот запрос" - а иначе тот не разберется что и как отдать, если не сумеет отдать нужное в запрошенном виде. Что, скорей всего, в нашем случае и имеет место быть. Да и дебажить новые карты сложнее ж. А езе и с Keep-Alive могут быть грабли. Возможно, сервер просто SOCKET_REUSE не умеет или не хочет, а от него настырно хотят именно этого. Отсюда наверное растет и факт того, что если подольше подолбиться - тайл таки скачается (сервер таки закроет Keep-Alive сокет в какое-то время, и создаст новый с нуля в ответ на очередной запрос?).

(0010725) vasketsov (manager) 01-03-2013 08:14 edited on: 01-03-2013 08:17	В "нашем случае имеет место быть" банальная "случайность": серваку говорят что надо преимущественно гзип но можно и жпег, но примем мы только жпег. Ну вот он и говорит что вы ребята офигели, кидается какашками в том случае, если посчитает целесообразным вернуть гзип. Работает только если он посчитает целесообразным вернуть жпег не ужимая. >с Keep-Alive могут быть грабли Вероятность этого 100%-99.(9)%. При тех же настройках через прокси (со своим KA и далее по цепочке) пример от Garl-а выше (где есть волшебные звёздочки /) будет работать.

(0010727) Parasite (administrator) 01-03-2013 08:32	>Ну вот он и говорит что вы ребята офигели, кидается какашками в том случае, если посчитает целесообразным вернуть гзип. Работает только если он посчитает целесообразным вернуть жпег не ужимая. Какая-то весьма изощренная логика на, повторюсь, ОДНОМ И ТОМ ЖЕ тайле. Я так понимаю, что при прочих равных - он его должен ЛИБО всегда отдавать, ЛИБО всегда нет если сервер что-то не устраивает. Алгоритм-то отдачи контента на его стороне фиксирован на 99.9% вероятности, скорее всего. У нас в ZMP - тоже. А результкт, как у того Троцкого - то туда, то сюда, то отдамся, то не отдамся, то отдамся только после долгой долбежки вокруг и около... >При тех же настройках через прокси (со своим KA и далее по цепочке) пример от Garl-а выше (где есть волшебные звёздочки /) будет работать. Это-то понятно. Мы просто перекрываем свой баг (или фичу?) ручками - и оно скорее всего заработает. Именно в этом случае. Но бага\фичи-то не отменяет. Оный я и предлагаю полечить - чтобы работало по дефолту. Проблема-то не в сервере, коль старой версии всё отдает ОК, да и браузеру - тоже. Путь скачки именно этой карты в данном тикете мне не нужен - она уже выкачана, вариантов лечения именно этой карты - тут не требуется. Предлагается разобраться, почему конкретно глючит именно дефолтный вариант хидеров - и полечить, засим всё. То есть, ввести те самые Garl'овы звездочки в дефолтный набор хидеров САСа (если с гзипом надо передавать именно звездочки), либо убрать Accept\gzip, или еще как. Просто чтобы этот вопрос больше не всплывал и на других возможных картах, и хомяки не ломали голову еще раз.

(0010728) vasketsov (manager) 01-03-2013 09:52	>Какая-то весьма изощренная логика на, повторюсь, ОДНОМ И ТОМ ЖЕ тайле. То что тайл один и тот же - роли не играет, так как в приведённом варианте решение загзиповать или нет тайл принимается исключительно сервером по одному ему ведомым основаниям (например по занятости рабочих потоков для гзипования). Как пример - на заре переделки формы поиска доступных снимков была ровно эта же проблема для нокии. Причём на одном и том же тайле (там выдирается exif из тайла) то работает, то нет (но на 3-4 раз сработает). Идея что сервер вот так вот халтурит подтвердилась на 100%. Он не обязан отдавать гзип или не гзип, и может вернуть что угодно. Когда я писал парсер для росреестра - я опять забыл об этом и опять налетел на ровно то же самое. >Но бага\фичи-то не отменяет Ещё раз: весь баг (это не фича, я гарантирую это) в том, что при указании Accept-Encoding: gzip указали только image/jpeg. Надо указывать просто / (или добавлять / в конец списка Accept). Разумеется он (этот баг) к конкретной карте не относится. >либо убрать Accept\gzip Очевидно это не вариант. Начиная от бана сервера в отношении неумеющих разжимать клиентов, и кончая банальным дцатикратным увеличением трафика. Если подумать - Accept-Encoding: gzip, deflate в идеале вообще должен быт всегда, как и добавление волшебных звёздочек в Accept. Броузеры именно так и делают, к слову, допуская сжатие контента.

(0010729) Parasite (administrator) 01-03-2013 10:29	>Начиная от бана сервера в отношении неумеющих разжимать клиентов Вроде как пока еще нет такого стандарта, чтобы любой отдельно взятый клиент либо безусловно умел разгзиповывать - либо Васю на мороз. Так что официальных поводов для бана таки не вижу. Не, ну понятно что на каждом сервере можно извратиться и накрутить какой угодно отсебятины - но банить за отсутствие умения гзипа это имхо перебор. Мне такие дикие ресурсы не попадались пока еще. >кончая банальным дцатикратным увеличением трафика. Ну не на жпегах же. :) Данный сервер, насколько я понимаю - чистый CDN, и гзипить там разве что хидеры от тех жпегов... а вебморда и прочие стили\явы лежат на более другом disney.com. Впрочем, это детали конкретно этого ресурса конечно же. >Если подумать - Accept-Encoding: gzip, deflate в идеале вообще должен быт всегда А я бы предложил наоборот: в дефолтовых САСовых хидерах оставить только самый минимальный минимум (GET/POST/HTTP, URL, Content-Length и прочий минимальный джентльменский набор), а все что свыше (включая гзиповку, управление кэшированием и прочие звездочки) - предложил бы вынести в ZMP именно тех карт, где это действительно нужно. Вот например на обсуждаемой карте - нет никаких экономических причин юзать гзип, так и зачем передавать его хидер серверу? Этот хидер скорее всего длиннее, чем экономия от гзипа.... Короче, предложил бы ограничиться минимально разумной достаточностью вшитой в САС, а все что может понадобиться конкретному юзеру свыше - высунуть наружу, в ЗМП. В этом случае, например, будет возможность отключить ненужное\глючашее сугубо силами хомяка, а не разработчика САСа. Например, отключить ненужный+глючащий на этой вот карте гзип я сейчас не смогу, а был бы он вынесен в ЗМП - то дело было бы в паре закомментированных строк, не теряя своего и вашего времени на этот вот тикет. >весь баг (это не фича, я гарантирую это) Что и требовалось доказать. Собссно, и вот. Чините-сс. :)

(0010730) zed (manager) 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 (manager) 01-03-2013 10:48	Подозреваю, что тут влияют настройки IE.

(0010733) Parasite (administrator) 01-03-2013 11:14	>Подозреваю, что тут влияют настройки IE. При этом в самом ИЕ - вся карта (через свою вебморду) работает? Не, не в нем дело скорей всего. Впрочем, пробуй: http://disneyworld.disney.go.com/maps/ (ох щщи - она саму себя еще и на HTTPS форвардит как оказывается, и далее так и с него и работает...Впрочем, только что попробовал тайлы по HTTPS - в новом сасе проблема и еррор ровно те же). >Полностью удалить строку Accept из запроса не представляется возможным, но добавить в конец / можно легко. А попробуй сбилдить и выложить? Я потестю, если ОК - то в этом и проблема. И еще сбилдить с Connection: Close вместо Keep-Alive тоже. PS: потестить смогу не раньше понедельника. Не горит, собссно...

(0010734) zed (manager) 01-03-2013 11:26	>При этом в самом ИЕ - вся карта (через свою вебморду) работает? Не, не в нем дело скорей всего. Я о строке "Accept-Encoding: gzip, deflate" - её наличие определяется скорее всего настройками IE. И когда эти настройки "не в тему" добавляются к нашим хидерам и получаем то что имеем.

(0010735) vasketsov (manager) 01-03-2013 11:26 edited on: 01-03-2013 11:28	>но банить за отсутствие умения гзипа это имхо перебор Не более перебористее нежели по UserAgent-у или кукам (которые отключабельные). >нет никаких экономических причин юзать гзип Как бы да, но покуда пути картосерверов неисповедимы, задача прикидываться броузером может быть более важна, нежели экономия на строке в заголовке. Впрочем согласен, что в крайнем случае это можно в скрипте указать. >Подозреваю, что тут влияют настройки IE Возможно Parasite пропихивает запрос через прокси, и там натягивается gzip. >добавить в конец / можно легко Есть подозрение, что это всех устроит, включая прокси-серверы и прочие картосерверы. Хотя пока что непонятно, почему вообще не указывать всегда только / и разбирать тип контента уже имея ответ на руках. Есть какая-то алгоритмическая проблема указать / во всех случаях, кроме прямого указания в хедере в скрипте чего надо пользователю? >И еще сбилдить с Connection: Close вместо Keep-Alive тоже Это заведомо лишнее.

(0010739) Parasite (administrator) 01-03-2013 13:13	>её наличие определяется скорее всего настройками IE. И когда эти настройки "не в тему" добавляются к нашим хидерам и получаем то что имеем. Тогда это какие-то весьма хитрые настройки IE, что добавляются и глючат исключительно к этой ночнушке и только на этой карте (причем не всегда, а в Trotsky-style), а штук 20 работающих на этой же машине в фоне САСов разных версий и степеней озадаченности разнообразными серверами - качают себе (при тех же настройках IE) и в ус не дуют. Уж скорее допущу что это локальный Сквид балуется - но опять же, через него идет всё и вся, и до сего момента ни единой проблемы с этим не было. >Возможно Parasite пропихивает запрос через прокси, и там натягивается gzip. Именно. Но про принудительный гзип там - не помню. Если и включал когда - то это было весьма давно, и проблем ни разу ни на одном ресурсе не доставляло. >Это заведомо лишнее. Сугубо проверки для. Был небольшой экспириенс, когда именно из-за невнятного проксифицирования этого вкупе с HTTP1.1 - была кучка малообъяснимых глюков. Zed должен это тоже помнить, собссно - с ним и решали. Благо что сбилдить с этой строчкой - как 2 пальца о консоль, а проверить - не повредит, и много времени не займет.

(0010740) zed (manager) 01-03-2013 13:35	>Есть какая-то алгоритмическая проблема указать / Как раз наоборот, клиент (Alcinoe) сам всегда подставляет / если не находит Accept в юзерских заголовках.

(0010741) vasketsov (manager) 01-03-2013 13:46	>клиент (Alcinoe) сам всегда подставляет / если не находит Accept в юзерских заголовках Именно такое поведение и хотелось бы поиметь в итоге

(0010867) Parasite (administrator) 14-03-2013 10:49	Тред заглох?

(0012639) vdemidov (manager) 28-08-2013 05:35	Ну и к чему пришли?

(0013761) zed (manager) 11-02-2014 19:07	Пришли к тому, что предлагают заменить Accept:image/jpg на Accept:/ всегда и везде, если юзер не указал иного сам через хидеры. Сейчас же в Accept мы подставляем ContentType из zmp.

(0013762) vdemidov (manager) 11-02-2014 21:14	Ну так что тебя останавливает в реализации?

(0013763) zed (manager) 12-02-2014 04:20	А тебя?

(0013764) vdemidov (manager) 12-02-2014 06:41	> А тебя? Ну хотя бы то, что это ты добавлял много лет назад https://bitbucket.org/sas_team/sas.planet.src/commits/c8d2b26d3dcba992839f97bd5c49af57d31a3064 И я понятия не имею для чего и какие карты отвалятся если убрать эту подстановку.

(0013765) zed (manager) 12-02-2014 16:58	Я это добавлял не для карт, а потому что новый компонент всегда отсылает поле Accept и были грабли с его инициализацией (баг 0001026). А конкретный ContentType я подставил тогда "за компанию" и ты даже занёс чего-то там в ToDo относительно него. Мне казалось что не помешает уведомить сервер о ожидаемом типе и я без понятия отвалятся ли какие-нибудь карты если это убрать.

(0013766) vdemidov (manager) 12-02-2014 17:14	Нее. До того коммита инициализация FHttpClient.RequestHeader.Accept := '/' уже была. Ты ее почему-то заменил. В общем что хочешь, то и делай с этим багом.

(0013767) zed (manager) 12-02-2014 17:22	> Ты ее почему-то заменил. Я ж говорю - за компанию. А то, что это не за один коммит прилетело - не суть. Это всё было к тому же в тестовой ветке Threaded - основная цель доработки там было прикрутить многопоточную качалку вместо однопоточной. > В общем что хочешь, то и делай с этим багом А шоб я ещё знал, что с ним делать, уже б давно сделал. Там это за пять минут делается: что оторвать, что добавить - одинаково легко и быстро.

(0013768) zed (manager) 12-02-2014 17:30	Да и что там с тем ToDo? Что ты там имел в виду?

(0013769) vdemidov (manager) 13-02-2014 06:17	В TODO я подразумевал, что нужно в параметры zmp добавить отдельное поле Accept. >А шоб я ещё знал, что с ним делать, уже б давно сделал. Там это за пять минут делается: что оторвать, что добавить - одинаково легко и быстро. Я тоже не знаю. Делай по своему усмотрению.

Users who viewed this issue
User List	Anonymous (3327x), vdemidov (2x)
Total Views	3329
Last View	20-04-2024 12:51

Issue History
Date Modified	Username	Field	Change
25-02-2013 08:46	Parasite	New Issue
25-02-2013 08:46	Parasite	File Added: disney.zmp
25-02-2013 08:48	Parasite	Note Added: 0010635
28-02-2013 17:39	vdemidov	Note Added: 0010703
28-02-2013 17:39	vdemidov	Status	new => feedback
28-02-2013 18:06	Parasite	Note Added: 0010705
28-02-2013 18:06	Parasite	Status	feedback => new
28-02-2013 19:31	vdemidov	Note Added: 0010707
01-03-2013 04:25	Garl	Note Added: 0010710
01-03-2013 05:03	Parasite	Note Added: 0010711
01-03-2013 05:37	zed	Note Added: 0010712
01-03-2013 06:32	Parasite	Note Added: 0010715
01-03-2013 06:59	Parasite	Note Added: 0010716
01-03-2013 07:01	Parasite	Note Edited: 0010716	View Revisions
01-03-2013 08:00	vasketsov	Note Added: 0010722
01-03-2013 08:08	Parasite	Note Added: 0010723
01-03-2013 08:12	Parasite	Note Edited: 0010723	View Revisions
01-03-2013 08:14	vasketsov	Note Added: 0010725
01-03-2013 08:14	vasketsov	Note Edited: 0010725	View Revisions
01-03-2013 08:17	vasketsov	Note Edited: 0010725	View Revisions
01-03-2013 08:32	Parasite	Note Added: 0010727
01-03-2013 09:52	vasketsov	Note Added: 0010728
01-03-2013 10:29	Parasite	Note Added: 0010729
01-03-2013 10:45	zed	Note Added: 0010730
01-03-2013 10:48	zed	Note Added: 0010731
01-03-2013 11:14	Parasite	Note Added: 0010733
01-03-2013 11:26	zed	Note Added: 0010734
01-03-2013 11:26	vasketsov	Note Added: 0010735
01-03-2013 11:28	vasketsov	Note Edited: 0010735	View Revisions
01-03-2013 13:13	Parasite	Note Added: 0010739
01-03-2013 13:35	zed	Note Added: 0010740
01-03-2013 13:46	vasketsov	Note Added: 0010741
14-03-2013 10:49	Parasite	Note Added: 0010867
28-08-2013 05:35	vdemidov	Note Added: 0012639
22-11-2013 22:21	vdemidov	Product Version	.Nightly => 131111
11-02-2014 09:51	vdemidov	Priority	high => low
11-02-2014 19:07	zed	Note Added: 0013761
11-02-2014 21:14	vdemidov	Note Added: 0013762
12-02-2014 04:20	zed	Note Added: 0013763
12-02-2014 06:41	vdemidov	Note Added: 0013764
12-02-2014 16:48	zed	Relationship added	related to 0001026
12-02-2014 16:58	zed	Note Added: 0013765
12-02-2014 17:14	vdemidov	Note Added: 0013766
12-02-2014 17:22	zed	Note Added: 0013767
12-02-2014 17:30	zed	Note Added: 0013768
13-02-2014 06:17	vdemidov	Note Added: 0013769
13-02-2014 07:33	vdemidov	Assigned To	=> zed
13-02-2014 07:33	vdemidov	Status	new => assigned
13-02-2014 07:33	vdemidov	Target Version	=> 140303
13-02-2014 08:02	zed	Status	assigned => resolved
13-02-2014 08:02	zed	Fixed in Version	=> 140303
13-02-2014 08:02	zed	Resolution	open => fixed

SASGIS