Формат MHT

Существует множество возможных вариантов построения системы управления контентом, и многие из них неплохо описаны.

Сегодня хотелось бы подробнее остановиться на использовании MHT формата для хранения контента. Для начала упомяну, что формат MHT основан на MIME кодировании и позволяет держать в одном файле текстовый и графический контент страницы. Подробнее о формате здесь. Начиная с версии 5.5, сохранение страниц в MHT поддерживается Internet Explorer. Более того, приложения пакета MS Office (например, Word и Publisher) также позволяют работать с MHT файлами. Отсюда и удобства применения формата:

• для конечных пользователей CMS - редактирование контента в любимом редакторе, что позволяет ориентироваться на пользователей с любым уровнем подготовки/знания HTML.
• для разработчиков: простота server-side работы с контентом. Страницы контента хранятся и обрабатываются как единая сущность, вне зависимости от наличия в них вложенных элементов (графики, анимации etc)

Главный минус формата - контент в MIME весит примерно на 33% больше, чем страница, сохраненная в html + вложения. Однако это ограничение можно обойти, воспользовавшись GZIP кодированием вложенных элементов страницы перед сохранением их в MIME.

Теперь немного о тонкостях работы с форматом на примере.

Задача

Предположим, наша CMS хранит файлы контента в базе и выводит страницы контента конечному пользователю напрямую из базы. То есть в Response мы записываем те самые mht файлы.

Кроме того, будем исходить из допущения, что mht файлы должны выводиться браузером напрямую,
без предварительной отгрузки контента в кеш браузера и последующего локального открытия файла.
Это позволит обеспечить прозрачныю работу с контентом для конечных пользователей, так, будто
они работают с простым html контентом.

Решение

Как обычно, есть два варианта проделать запись файла в Response:

1. создать пустую aspx страницу, codebehind-класс которой будет подбирать информацию о запрошенном контенте из Query String и выводить соответствующий файл в респонс;
2. создать handler, проделывающий то же самое.

В этом месте необходимо оговориться, что security особенности IE не позволяют:

• открыть в браузере MHT-файл с расшинением, отличным от .mht (.mhtml), даже если на сервере
  правильно указан content-type;
• открыть mht-файл в случае, если в реквесте присутствует query string. То есть, следующий URL 
  вернет нам 404, даже если указанный в нем файл действительно присутствует на сервере:

http://localhost/MyApp/Page.mht?id=1

Последнее обстоятельство может вызвать конфуз у разработчика. Причина подобного ограничения функциональности IE, как всегда, vulnerability issue.

Вышеизложенные замечания указывают нам путь решения поставленной задачи:

1. зарегистрировать в настройках приложения (IIS) расширение .mht как обрабатываемое aspnet_isapi.dll. Важно! Необходимо выключить checkbox проверки существования файла.
2. создать в приложении хендлер для расширения .mht, который не требует query string для передачи на сервер информации о запрошенной странице.

Для реализации второго пункта как вариант можно передавать параметры прямо в имени запрошенной страницы. То есть, URL будет выглядеть примерно так:

http://localhost/MyApp/ViewContentCategory10Type1.mht

Параметры из URL запрошенного файла подберем с помощью Regex, вот маленький пример:

HttpRequest Request = context.Request;
  HttpResponse Response = context.Response;
  int categoryId = -1;
  int type = -1;
  try
  {
   Match match = Regex.Match(Request.Path, 
@"(ViewContentCategory)(\d+)(Type)(\d+)",
RegexOptions.IgnoreCase);
   if (match != null)
   {
    categoryId = Convert.ToInt32(match.Groups[2].Value);
    type = Convert.ToInt32(match.Groups[4].Value);
   }
  }
  catch
  {}

После получения из базы byte[] с нужным файлом остается только правильно прописать его в Response:

 
public void WriteContentToResponse(byte[] content, 
HttpResponse Response)
  {  
   Response.BufferOutput = true;
   Response.Clear();
   Response.ContentType="message/rfc822";
   
   Response.BinaryWrite(content);
   Response.End();
  }

 

Проблема

Сборки, подгружаемые .NET приложением (автоматически или принудительно) блокируются процессом, в котором работает AppDomain приложения. В некоторых случаях небходимо, чтобы используемые процессом сборки оставались открытыми для записи (например, в ситуации постоянного обновления сборки).

Решение

.NET framework позволяет решить поставленную задачу путем принудительного включения механизма ShadowCopy при обращении к файлам. Таким образом, вместо оригинального файла в AppDomain будет использована его shadow copy, и оригинальный файл не блокируется доменом приложения. Флаг на использование shadow copy выставляется методом AppDomain.SetShadowCopyFiles()

Пример

В приведенном ниже примере сборка sl.dll останется незаблокированной.

 
Thread.GetDomain().SetShadowCopyFiles(); 
Assembly asm = 
Assembly.LoadFrom(@"D:\Projects\SL\bin\Debug\sl.dll"); 

В случае, если мы хотим обратиться к полю объекта сессии, и нам заранее неизвестен тип объекта, причем интерфейсное обращение также невозможно, на помощь придет библиотека Reflection.

В приведенном ниже примере метод GetDataSetFromSessionObject() вернет нам значение DataSet-поля объекта сессии, получая сведения о типе объекта, имени поля и собственно имени объекта динамически в runtime через QueryString:

protected string objectType;
protected string objectName;
protected string fieldName;
protected FieldInfo fi;
protected Type type;
...
protected DataSet GetDataSetFromSessionObject()
{
 objectType = Request["objectType"].ToString();
 objectName = Request["objectName"].ToString();
 fieldName = Request["fieldName"].ToString();
 object sessionObject = Session[objectName];
 type = System.Type.GetType(objectType);    
 fi = type.GetField(fieldName);
 return 
(DataSet)fi.GetValue((Convert.ChangeType(sessionObject, type)));
}