Стране остро не хватает галоперидола
Проблема у пользователя Эртериган. При попытке добавления дневника в Избранное или вступления в сообщество появляется алерт "Неверная ссылка на добавление в Избранное (вступление в сообщество)". Соответственно ни добавления, ни вступления не происходит. Попытки были, и не раз, F5 не помогает.
+при попытке удаления комментария или записи появляется алерт "неверная ссылка на удаление комментария/записи"
Браузер ИЕ 6.0.2900, ХР-SP2. Кэш очищался, на другом компьютере (браузер, версия аналогичны) та же проблема.
Поставлена Опера 9.27, то же самое.
С моего логина то же самое, и в ИЕ, и в Опере.
Решение, предложенное тут, не помогает.
+при попытке удаления комментария или записи появляется алерт "неверная ссылка на удаление комментария/записи"
Браузер ИЕ 6.0.2900, ХР-SP2. Кэш очищался, на другом компьютере (браузер, версия аналогичны) та же проблема.
Поставлена Опера 9.27, то же самое.
С моего логина то же самое, и в ИЕ, и в Опере.
Решение, предложенное тут, не помогает.
Разумным еще кажется проверить, сохраняется ли сессия (кука PHPSESSID, в Опере можно легко подсмотреть), прокси порой искажают и куки.
С другой стороны, если это работает с гпрса и не работает со стационарного соединения - проблема может быть в настройках конкретного соединения, а не у провайдера) полный полет фантазии
А все равно забавно, да? )) зачем передавать userid тогда
обрати внимание на ссылку "Добавить в избранное" в боковом меню дневников, там вообще его нет))
по-моему, раньше в этой ссылке адреса дневника не было, только ID, а теперь, видимо, оставили на всякий случай
Если это блокировка на стороне провайдера, то ниндзя должна помочь.
однако запросы/пакеты все равно проходят через провайдера, как ни крути. если он ссылки режет, то такие же урезанные отправит и на сторонний прокси. Нам здесь важно отследить только одно направление: отправка запроса на дайри. От пользователя любой запрос все равно пройдет через прокси-сервер провайдера (даже если он предназначен для прокси сервера, находящегося где-то в сети). Вопрос, в каком виде и по каким причинам он его отправит дальше.
проблема может быть в настройках конкретного соединения, а не у провайдера
не думаю, раз все остальное работает. В настройках соединения нет такой фигни, которая запрещает передавать параметры в ссылках (если тока не локальный файрвол и тп)
обрати внимание на ссылку "Добавить в избранное" в боковом меню дневников
да.. ну на всякий случай, так на всякий случай)
diary.photonid.com/~fav-add-test/?fav_add&useri... (даже потыкать по ссылке, там каждый раз новая signature).
хотя мне это кажется мистикой. параметр fav_add не может быть вырезан, иначе сервер не опознал бы запрос; а чем провайдеру не нравится параметр signature или что-то-типа-md5-хэш?
В настройках соединения нет такой фигни, которая запрещает передавать параметры в ссылках (если тока не локальный файрвол и тп)
ну, файрволл вроде отрубали. а в настройках соединения может быть прописан прокси + драйвера иногда выпендриваются)
в настройках соединения может быть прописан прокси
который принадлежит (вероятнее всего) провайдеру инета. так что виноват провайдер))
+ драйвера иногда выпендриваются)
ну вообще тут есть вероятность, но мне кажется оооочень низкая, так как почти на все сетевые карточки ставятся дрова по-дефоулту виндой
а чем провайдеру не нравится параметр signature или что-то-типа-md5-хэш?
по-моему некоторые провайдеры частенько их режут. для чего? вероятно, в целях безопасности, так как порой с их помощью можно выполнить нехорошие действия на стороне сервера. наверное страхуются от взлома и утечки трафика
думаю это имеет к теме некоторое отношение
--------
Макс, но не из Ехо
то что все работает при смене поставщика инета однозначно вычеркивает баги на компе и дает наводку на прокси-сервер провайдера.
Теперь встает вопрос, что именно предъявить провайдеру, чтобы не наткнуться на стандартную отмазку типа "на нашей стороне все работает, перезагрузите машину"))
Какой консилиум)) "но касторку дать обязательно"^^ не помню, говорил уже или нет)
сидимфлудим" ))так. мое предложение - с твоего компа через глючащего провайдера ты проходишь по моей ссылке выше и сравниваешь то, что в адресной строке браузера, с содержанием страницы, вернее, с пунктом URI. ) Там же новая ссылка будет, можно еще пару раз потыкать. Если где-нибудь что-нибудь не совпадет - можно идти к провайдеру и требовать, чтобы ссылки конкретно вот такого вида заработали.
Если все совпадет - значит, проблема не в параметре signature, и мы ждем UsUal gUy'а с новыми идеями. )
Совпадает. Для чистоты эксперимента потыкал 15 раз
и мы ждем UsUal gUy'а с новыми идеями. )
а идея одна.
у нас есть 2 схемы. У нас работает вот такая схема:
[компьютер]-1->[провайдер]-2a->[ninjaproxy.com]-2b->[дайри]
и вот такая:
[компьютер]-1->[провайдер]-2с->[diary.photonid.com]
а вот такая не работает
[компьютер]-1->[провайдер]-2->[дайри]
То есть ошибка возникает где-то в узле 2.
Если работает 2c, то сам провайдер вероятно не причем.
Тут теперь строго 2 варианта:
1 Ошибка возникает на каком-то сервере (маршрутизаторе), являющимся узлом на пути между серваком провайдера и дайри.
2 Ошибка обработки запроса на дайри. Тогда вопрос почему не у всех и не всегда. Хорошо бы подобную тестилку вывесили программисты, только не с твоим алгоритмом получения параметров, а именно с тем, который используется при обработке этого запроса.
я склоняюсь к первому.
Предлагаю сравнить маршруты до сервера дайри и до сервера photonid.com. Найти где начинается разница и дальше.. проверять каждый узел)) как именно пока - не знаю (зависит от того, что за ip-шник будет выдан)
Проверяется это так. Запускается командная строка (кнопка пук -> выполнить -> набрать с клавиатуры cmd -> жмахаем enter)
В ней набираем:
TRACERT diary.ru >>C:\TraceDiary.txt
комп на вреям задумается, потом снова отобразит строку приглашения - в файле TraceDiary.txt на диске C появится таблица с маршрутом пакета (ip каждого сервера, через который проходит запрос)
далее набираем снова
TRACERT photonid.com >>C:\TracePhotonid.txt
Открываем эти 2 файла (TraceDiary.txt и TracePhotonid.txt) и ищем различия.
Ну вот например у меня. Маршрут A до дайри:
А вот маршрут B до photonid
Одинаковые начальные части маршрутов выделены курсивом.
То есть если бы у меня была ошибка, то она могла возникнуть на узлах 4-6 маршрута А (если исключить глюк на самом дайри). То есть проверить на "съедание" сигнатур нужно всего 3 узла. Вопрос "как" открыт (особенно если узел - это просто маршрутизатор).
2 101 ms 124 ms 85 ms gw1.e-sky.ru [85.92.9.1]
3 222 ms 92 ms 107 ms ebg15.transtelecom.net [217.150.61.134]
4 100 ms 141 ms 111 ms ruscomnet-gw.transtelecom.net [217.150.56.85]
5 289 ms 159 ms 159 ms masterhost-gw.ruscomnet.ru [80.249.128.2]
6 189 ms 157 ms 159 ms fe67.masterhost.ru [83.222.23.137]
слушай, я искренне полагал, что до моего хоста роутинг идет через РТКОММ)) сорри тогда)
но так мы найдем узлы, по которым идет TCP, а HTTP-прокси здесь может не всплыть вовсе)
а кому потом будем стучаться? провайдер уже не при чем) или требовать, чтобы другой маршрут задали?)
*затыкается и внимательно следит за дальнейшим развитием дискуссии* больше я ничем помочь не смогу, у меня ни знаний, ни проблемы не имеется)
это не мне ли?... например, URL аякс-запроса содержит компонент &js
проверить легко - вместо того, чтобы просто тыкать по ссылке добавления в избранное, открываем ее в новом окне (через контекстное меню) и смотрим, что появится в этом новом окне. если все заработает - значит, в аяксе проблема
1 <1 ¬б <1 ¬б <1 ¬б 192.168.2.1
2 1 ms <1 ¬б <1 ¬б 33.141.229.87.e-tagil.ru [87.229.141.33]
3 1 ms 1 ms 1 ms bgp.e-tagil.ru [82.195.26.1]
4 5 ms 3 ms 4 ms 87.229.128.114
5 5 ms 5 ms 4 ms c7304-ge2-352-vl352.blh.yek.foratec.net [84.254.192.154]
6 6 ms 6 ms 8 ms 195.161.94.249
7 35 ms 35 ms 36 ms 217.106.1.150
8 35 ms 33 ms 37 ms 217.106.1.150
9 36 ms 36 ms 35 ms www.diary.ru [81.176.66.114]
Маршрут до Фотонида:
1 <1 ¬б <1 ¬б <1 ¬б 192.168.2.1
2 <1 ¬б <1 ¬б <1 ¬б 33.141.229.87.e-tagil.ru [87.229.141.33]
3 1 ms <1 ¬б <1 ¬б bgp.e-tagil.ru [82.195.26.1]
4 5 ms 5 ms 5 ms 87.229.128.114
5 7 ms 4 ms 5 ms c7304-ge2-352-vl352.blh.yek.foratec.net [84.254.192.154]
6 5 ms 6 ms 6 ms 195.161.94.249
7 35 ms 33 ms 35 ms msk-dsr5-ge1-48.rt-comm.ru [217.106.0.2]
8 35 ms 35 ms 33 ms msk-dsr5-ge1-48.rt-comm.ru [217.106.0.2]
9 34 ms 36 ms 34 ms msk-dsr5-masterhost.c.rt-comm.ru [195.161.4.62]
10 35 ms 33 ms 33 ms msk-ar-9-vl11.masterhost.ru [217.16.23.129]
11 36 ms 35 ms 33 ms fe67.masterhost.ru [83.222.23.137]
Совпадения до 6 пункта.
Аякс не причём. продлема остаётся.
мы найдем узлы, по которым идет TCP, а HTTP-прокси здесь может не всплыть вовсе)
Так прокси не может висеть в воздухе. Он будет на одном из узлов (если он - сервер, а не просто маршрутизатор).
а кому потом будем стучаться? провайдер уже не при чем) или требовать, чтобы другой маршрут задали?)
а ни к кому собственно)) ну можно найти владельца узла после которого съедается сигнатура (через whois), и сказать, что он бяка такой, пусть чинит немедленно, но че-то я сомневаюсь, что это подействует) Второй вариант - указать провайдеру "скользкий" айпи, и он уже, как заинтересованное лицо, будет сам разбираться, чего такого на том маршруте.
господа, а то, что проблема не в ajax-запросе, мы уже проверили?
В самом начале. Я писал, что если его даже совсем убрать, то просто перекинет на страничку с надписью "Добавлено" как в старые добрые времена.
Однако попробовать (у кого есть проблема) явно не помешает. Если проблема в аяксе, то можно его просто вырубить (ведь его вроде можно вырубить, да? )
--------
Макс, но не из Ехо
у меня ни знаний, ни проблемы не имеется)
а проблема уже пропала?
Так все ж работает, если подключение поменять. Я не понимаю^^'
когда ты меняешь подключение, меняется и маршрут по которому бегут запросы от тебя. Видимо, минуя тот узел, после которого запрос обрезается.
Опять же, это так, если только только на самом деле до дайри запрос доходит в обгрызанном виде. А это можно проверить наверняка только, если будет написана тестовая страничка с выводом дошедших до дайри параметров.
замечательно. Если проблема есть, то она может быть только на одном узле: 217.106.1.150
блин... но у меня маршрут тоже проходит через этот узел..
глюк на самом дайри?
--------
La personne mystique
может подключить глюкера, а? все равно нужен кто-то, кто сможет отследить, что дошло до сервера, а что нет (кто имеет доступ)
А почему решили, что проблема в одном конкретном узле? У нас еще три узла е-tаgil имеются, которые ничем не подтвердили свою надежность..
АrLе, это тестерам скучно) Вот и завели дело о краже запросов))) *мы еще и не такое сейчас развернем*
Брат, ну давай еще трассировку с гпрса для чистоты эксперимента...)
UsUal gUy, 217.106.1.150 - это и есть РТКОММ (msk-dsr6-tg3-1.rt-comm.ru), моя трассировка тоже через него проходит)
так, мне как-то с утра не думается, но интуиция почему-то все равно за то, что проблема локальная >.<
можно попросить Эртеригана поставить Фиддлер и через него ходить, а глюкера - при ошибке выводить REQUEST_URI в комменте, тогда получится полный мониторинг запроса)
ArLe, больше ничего интересного не происходит -_-
Это какой-то прямо сетевой детектив!
можно уже сценарий для фильма писать ))
Макс, но не из Ехо
У нас еще три узла е-tаgil имеются, которые ничем не подтвердили свою надежность..
Ну так-то косвенно подтвердили, так как они участвовали во 2ом маршруте при отправке запроса на photonid.com, куда параметры, как я понял, дошли (15 из 15 раз). Там узлы с 1го по 6ой совпадают.
Ждем от тебя результата по ссылке gluker'а.
--------
La personne mystique
но интуиция почему-то все равно за то, что проблема локальная >.<
я уже не знаю. я скоро здамся. остался самый последний вариант - проверить ссылку, что сделал gluker. и узнать, наконец, какая ссылка доходит до дайри.
--------
gluker
Спасибо большое! осталось дождаться Макса.
П.С. Я не Эртериган, если что, мы даже не похожи)
Да, для чего ссылочка-то? Мне она бесполезна, а брат на сообщество не зайдет, у него доступа нет...
Копирните сюда плз, я не в состоянии^^'
beta.diary.ru/test/?fav_add&userid=57570&signat...
beta.diary.ru/test/?fav_add&signature=f7e1c2a93...
о, я только что обнаружил, что при аякс-добавлении в избранное сигнатура передается дважды
Так точно. На сообщество не попал.
La personne mystique
сигнатура передается дважды
Что из этого следует? Что обрезание может быть при второй передаче?
Макс, но не из Ехо
мы даже не похожи
Разве что жизненной позицией
До Дайри
1 557 ms 850 ms 880 ms 172.30.2.20
2 600 ms 629 ms 654 ms 172.30.2.19
3 757 ms 600 ms 679 ms gprs2.ycc.ru [217.148.52.178]
4 549 ms 636 ms 649 ms gi0-1-c7206-ms.ycc.ru [217.148.52.33]
5 628 ms 700 ms 639 ms ge-3-0-0-102.r2.ekt5.relan.ru [217.148.63.81]
6 580 ms 645 ms 759 ms ge-0-0-0-0.br1.ekt6.relan.ru [217.148.63.99]
7 520 ms 743 ms 805 ms Ekaterinburg19-FE1-0-47.rosprint.net [195.151.250.162]
8 649 ms 689 ms 674 ms Ekaterinburg-GIN-PE02.rosprint.net [195.151.231.49]
9 732 ms 574 ms 720 ms Ekaterinburg01.rosprint.net [194.84.77.97]
10 528 ms 620 ms 659 ms Moscow01-A5-1-0.58.rosprint.net [195.151.240.106]
11 601 ms 725 ms 667 ms Moscow43-GE0-2.rosprint.net [193.232.88.4]
12 669 ms 602 ms 754 ms msk-dsr2-ge2-0-0-368.rt-comm.ru [213.59.1.5]
13 720 ms 689 ms 619 ms 217.106.1.150
14 509 ms 562 ms 729 ms 217.106.1.150
15 575 ms 639 ms 626 ms www.diary.ru [81.176.66.114]
До Фатонида
1 751 ms 595 ms 684 ms 172.30.2.20
2 523 ms 582 ms 524 ms 172.30.2.19
3 455 ms 649 ms 719 ms gprs2.ycc.ru [217.148.52.178]
4 605 ms 801 ms 832 ms gi0-1-c7206-ms.ycc.ru [217.148.52.33]
5 511 ms 574 ms 551 ms ge-3-0-0-102.r2.ekt5.relan.ru [217.148.63.81]
6 574 ms 585 ms 598 ms ge-0-0-0-0.br1.ekt6.relan.ru [217.148.63.99]
7 574 ms 657 ms 778 ms Ekaterinburg19-FE1-0-47.rosprint.net [195.151.250.162]
8 633 ms 649 ms 655 ms Ekaterinburg-GIN-PE02.rosprint.net [195.151.231.49]
9 349 ms 721 ms 573 ms Ekaterinburg01.rosprint.net [194.84.77.97]
10 599 ms 760 ms 674 ms Moscow01-A5-1-0.58.rosprint.net [195.151.240.106]
11 657 ms 652 ms 726 ms Moscow43-GE0-2.rosprint.net [193.232.88.4]
12 997 ms 1098 ms 641 ms 217.16.17.97
13 830 ms 594 ms 611 ms msk-ar-9-vl11.masterhost.ru [217.16.23.129]
14 620 ms 603 ms 561 ms fe67.masterhost.ru [83.222.23.137]
Совпадение до 11 пункта