Комментарии 76
Перенесите в ненормальное программирование ;)
Спасибо! В этой связи, Оперу и Огнелис в каждый комп.
Глаза бы мои не видели этого говнокода.
Можно конечно но зачем ???
Можно конечно но зачем ???
А скрипты можно так подключать через link?
Думаю нет, иначе бы это была бы большая дыра в защите, имхо.
Никакой дыры не вижу. И то, и то (документ и заголовки) — части одного целого, HTTP Response. Формируются одновременно веб-сервером.
Раз уж была возможность эмулировать заголовки в документе (в HTML это <meta http-equiv="..." content="..."/>), то вот еще есть эмуляция элементов документа в заголовках. Если браузер не будет трактовать скрипты, указанные в Link: как-то иначе, чем скрипты, указанные в теле документа — дыре возникнуть не с чего. Даже HTTP headers smuggling тут вроде никак не применить.
Другое дело, что это вообще богопротивное занятие — пихать сущности в непредназначенное для них место %)
По RFC 5988 предполагалось, afaik, что в заголовках будут передаваться ссылки, независимые от миме-типа и сериализации ресурса. А stylesheet, по правде говоря, не назовешь независимым. Это предназначено для rel вида previous или next.
Раз уж была возможность эмулировать заголовки в документе (в HTML это <meta http-equiv="..." content="..."/>), то вот еще есть эмуляция элементов документа в заголовках. Если браузер не будет трактовать скрипты, указанные в Link: как-то иначе, чем скрипты, указанные в теле документа — дыре возникнуть не с чего. Даже HTTP headers smuggling тут вроде никак не применить.
Другое дело, что это вообще богопротивное занятие — пихать сущности в непредназначенное для них место %)
По RFC 5988 предполагалось, afaik, что в заголовках будут передаваться ссылки, независимые от миме-типа и сериализации ресурса. А stylesheet, по правде говоря, не назовешь независимым. Это предназначено для rel вида previous или next.
Если у вас есть доступ к серверу, с которого загружается iframe, то что мешает этот скрипт прямо в коде указать? :) Так что этот способ ничем не отличается от обычного <link />.
И что? Если я могу отправить скрипт в заголовке, что помешает отправить такой же в теле ответа?
и чем будет отличаться от обычного тега link или script в этом случае?
Если бы все браузеры это поддерживали, то можно было бы сделать косвенную защиту своих стилей и скриптов. Так как не всякий может догадаться, что скрипты подключаются таким образом.
Забудьте, не бывает никаких «косвенных защит» и «security through obscurity».
Privacy надо заменить на security
в лисе стилем можно подгружать XBL используя -moz-binding
Контент в CSS еще хуже чем разметка таблицами…
А так в качестве разминки можно сделать
А так в качестве разминки можно сделать
И нахуя?
Кто-то пытается это серьезно воспринимать?! Это же, в большей степени, just for fun!!!
А тоже самое проделать, но оставить код валидным слабо? ;)
В Мозилле еще круче — Ctrl+U — и исходный код вообще пустой! Я сначала не поверил ))
Интересный хак. За заголовок link особое спасибо — пригодится, думаю.
В комплекте с JS обфускаторами может пригодиться…
Вспоминается анекдот про строку в исходниках:
set true=false;//Счастливой отладки, с_ки!
Вспоминается анекдот про строку в исходниках:
set true=false;//Счастливой отладки, с_ки!
В любом RFC, если почитать вдумчиво, есть свои интересные особенности, которые, будь они популяризированы ранее, могли бы перевернуть девелопмент в сфере этого RFC. Это обычное дело.
В принципе, способ передачи ресурсов через хёдер является более красивым и удобным, жаль что о нём вспоминают только перечитывая RFC в моменты безделия.
В принципе, способ передачи ресурсов через хёдер является более красивым и удобным, жаль что о нём вспоминают только перечитывая RFC в моменты безделия.
Что-то Вебкитные браузеры не проглотили хак… вижу только favicon и всё.
Потому что вебкит не поддерживает пока что Link header. Если интересно, вот бага с этим связанная.
Добавил ссылки на описание багов, что Link header не работает в вебкит и ие.
Вот скажите мне пожалуйста, где это можно применить, и какой от этого реальный толк.
+ не все браузеры данный финт поддерживают
+ не все браузеры данный финт поддерживают
Офигеть!
Большое спасибо за статью, очень интересная статья.
Не первый год занимаюсь веб-дизайном и версткой и меня очень трудно удивить всякими трюками на HTML/CSS, но вот это статья действительно удивила и заинтересовала.
Большое спасибо за статью, очень интересная статья.
Не первый год занимаюсь веб-дизайном и версткой и меня очень трудно удивить всякими трюками на HTML/CSS, но вот это статья действительно удивила и заинтересовала.
В качестве предисловия к переводу. Открываем Firefox/Opera, переходим по ссылке, смотрим исходный код страницы и удивляемся. Потому что его нет. Под катом рассказ, как такое можно сделать.
Перехожу по ссылке, смотрю исходный код страницы и удивляюсь! Исходного кода нет! Также нет и какого-либо содержания на данной странице! Далее читаю: «Под катом рассказ, как такое можно сделать.» — эээ, как сделать пустую страницу без исходного кода что-ли? Ржу под столом! xD
PS: Да-да-да, я зашел через Google Chrome, а на «Открываем Firefox/Opera» не обратил внимания =)
«Многие может и не знают, что использование тегов, и не является обязательным»
…
«Это происходит потому, что не найдя описанных выше тегов при рендеринге, браузер сгенерирует их сам.»
Мне кажется, что такое поведение браузера неправильно…
То есть эти теги необязательные, если их нет — не надо ничего генерировать.
…
«Это происходит потому, что не найдя описанных выше тегов при рендеринге, браузер сгенерирует их сам.»
Мне кажется, что такое поведение браузера неправильно…
То есть эти теги необязательные, если их нет — не надо ничего генерировать.
Тег в HTML5 обязателен по стандарту. Просто браузеры содержат в себе вот такую вот защиту от дурака-верстальщика.
HTML валидатор так не считает, если указать <!DOCTYPE html>
Firebug усё показывает :)
После < точку с запятой поставить забыли.
Какая от этого практическая польза?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
CSS трюки — пишем сайт без html