Каковы последствия перенаправления изображений за тегом <image>? - PullRequest
6 голосов
/ 31 августа 2009

Некоторые настройки:

У нас есть несколько статических изображений, доступных для общественности. Однако мы хотим иметь возможность ссылаться на эти изображения с помощью альтернативных URL-адресов в теге изображения. Так, например, у нас есть изображение с URL-адресом вроде:

http://server.com/images/2/1/account_number/public/assets/images/my_cool_image.jpg

И мы хотим вставить это в наш передний html как:

<img src="http://server.com/image/2/my_cool_image.jpg">

вместо

<img src="http://server.com/images/2/1/account_number/public/assets/images/my_cool_image.jpg">

Одним из действительно удачных решений, которое мы придумали, является использование перенаправлений 301. Теперь наше тестирование дало довольно неплохие результаты (все браузеры текущего поколения работают), но мне интересно, есть ли предостережения в этом подходе, которые я могу пропустить.

РЕДАКТИРОВАТЬ: Чтобы уточнить, причина, по которой мы хотим использовать этот подход, заключается в том, что мы также планируем использовать внешний хост для обслуживания ресурсов, и мы хотим иметь возможность отключить это время от времени. Таким образом, возможно, URL-адрес будет

http://client.com/image/3/cool_image.jpg

в дополнение к " default " способу доступа

Ответы [ 3 ]

13 голосов
/ 31 августа 2009

Другой метод, который не требует обхода сервера, заключается в использовании вашего HTTP-сервера, эквивалентного «механизму перезаписи» . Это позволяет вам указать в конфигурации сервера, что запросы на один URL-адрес должны удовлетворяться путем отправки результатов для некоторого другого URL-адреса. Это более эффективно, чем сказать браузеру «нет, иди посмотри туда».

2 голосов
/ 01 сентября 2009

Одним из возможных недостатков может быть SEO - длинное и сложное имя файла с общими именами папок может помешать более короткому URL-адресу.

Основная проблема в том, что для каждого изображения будет дополнительный HTTP-запрос. В общем, вы должны попытаться минимизировать HTTP-запросы для повышения производительности. Я думаю, что вы должны переписать URL-адреса для более длинных версий за кулисами, как говорили другие.

Вам не нужно переписывать весь URL с окончательным URL. Если вы хотите немного больше гибкости, вы можете переписать изображения следующим образом:

http://server.com/image/2/my_cool_image.jpg

Переписано как:

http://server.com/getImage?id=2&name=my_cool_image.jpg

Затем скрипт getImage считывает файл конфигурации либо обслуживает файл с более длинными именами на server.com, либо другой файл с client.com. У вас есть только одна поездка на сервер и незначительные накладные расходы на самом сервере, незаметные для посетителя.

1 голос
/ 31 августа 2009

Единственный реальный недостаток - это второй поиск DNS и небольшая нагрузка на сервер для расчета перенаправления, которые оба влияют на производительность. В противном случае я не могу думать ни о какой проблеме с этой техникой.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...