У нас есть сайт, к которому получают доступ полностью по HTTPS, но иногда отображайте внешнее содержание, которое является HTTP (изображения от каналов RSS, главным образом). Подавляющее большинство наших пользователей также застревает на IE6.
Я идеально хотел бы сделать оба из следующих
Я подозреваю, что первая цель просто не возможна, но второе может быть достаточным.
Худший вариант развития событий - то, что я анализирую каналы RSS, когда мы импортируем их, захватываем изображения, хранят их локально так, чтобы пользователи могли получить доступ к ним тот путь, но он походит на большое количество боли для довольно небольшого усиления.
Ваш худший сценарий не так плох, как вы думаете.
Вы уже разбираете RSS-канал, поэтому у вас уже есть URL-адреса изображений. Скажем, у вас есть URL изображения, например http://otherdomain.com/someimage.jpg
. Вы переписываете этот URL как https://mydomain.com/imageserver?url=http://otherdomain.com/someimage.jpg&hash=abcdeafad
. Таким образом, браузер всегда будет делать запрос по https, и вы избавитесь от проблем.
Следующая часть - создание прокси-страницы или сервлета, который делает следующее -
Это решение имеет некоторые преимущества. Вам не нужно загружать изображение во время создания html. Вам не нужно хранить изображения локально. Кроме того, вы не имеете состояния; url содержит всю информацию, необходимую для обслуживания изображения.
Наконец, хэш-параметр служит для безопасности; вы хотите, чтобы ваш сервлет обслуживал изображения только по созданным вами url. Поэтому, когда вы создаете url, вычислите md5(image_url + secret_key)
и добавьте его в качестве хэш-параметра. Перед тем как обслужить запрос, пересчитайте хэш и сравните его с тем, что было передано вам. Поскольку секретный_ключ известен только вам, никто другой не сможет составить правильный урл.
Если вы разрабатываете на java, сервлет состоит всего из нескольких строк кода. Вы должны быть в состоянии перенести приведенный ниже код на любую другую технологию back-end.
/*
targetURL is the url you get from RSS feeds
request and response are wrt to the browser
Assumes you have commons-io in your classpath
*/
protected void proxyResponse (String targetURL, HttpServletRequest request,
HttpServletResponse response) throws IOException {
GetMethod get = new GetMethod(targetURL);
get.setFollowRedirects(true);
/*
* Proxy the request headers from the browser to the target server
*/
Enumeration headers = request.getHeaderNames();
while(headers!=null && headers.hasMoreElements())
{
String headerName = (String)headers.nextElement();
String headerValue = request.getHeader(headerName);
if(headerValue != null)
{
get.addRequestHeader(headerName, headerValue);
}
}
/*Make a request to the target server*/
m_httpClient.executeMethod(get);
/*
* Set the status code
*/
response.setStatus(get.getStatusCode());
/*
* proxy the response headers to the browser
*/
Header responseHeaders[] = get.getResponseHeaders();
for(int i=0; i<responseHeaders.length; i++)
{
String headerName = responseHeaders[i].getName();
String headerValue = responseHeaders[i].getValue();
if(headerValue != null)
{
response.addHeader(headerName, headerValue);
}
}
/*
* Proxy the response body to the browser
*/
InputStream in = get.getResponseBodyAsStream();
OutputStream out = response.getOutputStream();
/*
* If the server sends a 204 not-modified response, the InputStream will be null.
*/
if (in !=null) {
IOUtils.copy(in, out);
}
}
Не знаю, подойдет ли это к тому, что вы делаете, но в качестве быстрого исправления я бы "обернул" содержимое http в сценарий https. Например, на вашей странице, обслуживаемой через https, я бы представил iframe, который заменил бы ваш RSS-канал, а в атрибуте src iframe поместил URL-адрес сценария на вашем сервере, который захватывает канал и выводит html. сценарий читает ленту через http и выводит ее через https (таким образом «оборачиваясь»)
Просто мысль
Что касается вашего второго требования - вы можете использовать событие onerror, т.е.
Обновление:
Вы также можете попробовать выполнить итерацию document.images
в dom. Существует логическое свойство complete
, которое вы могли бы использовать. Я не знаю наверняка, подойдет ли это, но, возможно, стоит изучить.
Просто: НЕ ДЕЛАЙТЕ ЭТОГО. Http-контент внутри HTTPS-страницы по своей сути небезопасен. Точка. Вот почему IE показывает предупреждение. Избавление от предупреждения - глупый подход.
Вместо этого, HTTPS-страница должна иметь только HTTPS-содержимое. Убедитесь, что содержимое может быть загружено через HTTPS, и ссылайтесь на него через https, если страница загружается через https. Для внешнего контента это будет означать загрузку и кэширование элементов локально, чтобы они были доступны через https - конечно. К сожалению, это невозможно обойти.
Предупреждение сделано по веской причине. Серьезно. Потратьте 5 минут на то, чтобы подумать, как вы можете захватить страницу с пользовательским контентом, отображаемую по https - вы будете удивлены.