Перезапись облака Rackspace jpg вызывает сброс сессии

Это может быть.NET-версия этого вопроса.

У меня есть скрипт изображения со следующим:

...
Response.WriteFile(filename);
Response.End();

Я переписываю файлы.jpg, используя следующее правило перезаписи в web.config:

<rule name="Image Redirect" stopProcessing="true">
  <match url="^product-images/(.*).jpg" />
  <conditions>
    <add input="{REQUEST_URI}" pattern="\.(jp?g|JP?G)$" />
  </conditions>
  <action type="Rewrite" url="/product-images/ProductImage.aspx?path=product-images/{tolower:{R:1}}.jpg" />
</rule>

Он просто переписывает путь к изображению в параметр запроса.

Проблема в том, что (периодически, конечно) Mosso возвращает новый файл cookie Session ASP, который разрушает весь мир.

  • Непосредственный доступ к статическому файлу.jpg не вызывает этой проблемы.
  • Прямой доступ к сценарию изображения также не вызывает его.
  • Только перезапись файла.jpg в сценарий.aspx приводит к потере сеанса.

Это не цикл перенаправления - изображение появляется, но сервер кэша отправляет новый файл cookie сеанса, который (поскольку он исходит от моего имени хоста) вызывает сброс сеанса.

Вещи, которые я пробовал

(Из документации Rackspace Как я могу обойти кеш?)

я добавил Private Кэшируемость к самому сценарию изображения:

Response.Cache.SetCacheability(HttpCacheability.Private);

Я попытался добавить эти отключающие кеш узлы в web.config:

<staticContent>
  <clientCache cacheControlMode="DisableCache" />
</staticContent>

а также

<httpProtocol>
  <customHeaders>
    <add name="Cache-Control private" value="Cache-Control private"
  </customHeaders>
</httpProtocol>

Решение мне нужно

Кэш браузера не может быть отключен. Это означает потенциальные решения, включающие Cache.SetNoStore() или же HttpCacheability.NoCache не будет работать.

С другой стороны...

Пожалуйста, скажите мне, почему это невозможно исправить.

Источник

2 ответа

Решение

Попробуйте использовать httphandler вместо перезаписи URL. Если перезапись вызывает проблему в Rackspace Cloud, то это должно решить проблему, поскольку исключает использование перезаписи:

Создайте класс httphandler в вашей папке App_Code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.IO;
/// <summary>
/// Summary description for ProductImageHandler
/// </summary>
public class ProductImageHandler : IHttpHandler
{
    public ProductImageHandler()
    {

    }

    #region IHttpHandler Members

    public bool IsReusable
    {
        get { return true; }
    }

    public void ProcessRequest(HttpContext context)
    {
        context.Response.ContentType = "image/jpg";

        // get path to image
        string pathString = Path.GetFileNameWithoutExtension(context.Request.RawUrl);

        // open file
        // ... insert your logic for manipulating pathString
        // so that it points to file you want to output
        // maybe something like pathString = "~/images/" + pathString + ".jpg";

        context.Response.WriteFile(pathString);
    }

    #endregion
}

А затем настройте записи в вашем web.config файл, так что этот обработчик получает отправленные запросы для файлов JPEG в папке "/product-images/":

<httpHandlers>
    <add verb="*" path="*/product-images/*.jpg" type="ProductImageHandler" validate="false"/>
</httpHandlers>

А также для интегрированного режима IIS:

<handlers>
    <add name="ProductImageHandler" preCondition="integratedMode" verb="*" path="*/product-images/*.jpg" type="ProductImageHandler"/>
</handlers>

И последнее: вам, вероятно, придется создать физическую папку с именем "product-images", чтобы IIS не возвращал 404, когда не может найти эту папку.

Еще одна вещь, на которую следует обратить внимание, это то, что это, вероятно, лучший способ выполнить то, что вам нужно сделать, потому что обработчики http не должны проходить нормальный жизненный цикл страницы ASP.NET, что означает, что для этого требуется меньше памяти и времени на выполнение. сервер.

Удачи, чувак!

Источник

Оказывается, это ограничение, которое Rackspace не может исправить.

Чтобы решить эту проблему, мне пришлось использовать другой поддомен для размещения изображений (images.site.com). Субдомен был просто псевдонимом основного сайта, но имя хоста не давало сбросу Session на www.site.com.

Я добавил некоторые изменения, чтобы указать на мой скрипт, обрабатывающий поиск изображений в Web.Config, чтобы сохранить изображения, возвращаемые из этого субдомена, и перенаправить обратно, если пользователь просматривал этот субдомен напрямую.

Кроме того, я подозреваю, что ответ Рэйфа ниже решил бы проблему также. Если вы столкнулись с этой проблемой, это решение, которое вы должны стремиться!

Источник
Другие вопросы по тегам