HttpResponse. Конец по сравнению с HttpResponse. Близко по сравнению с HttpResponse. SuppressContent
Походит на вид задания, которое можно было бы заставить небольшую компанию-разработчика программного обеспечения делать для Вас...
более серьезно, существуют сервисы, которые предоставляют интерфейс каталогу ISBN, www.literarymarketplace.com.
На worldcat.com, Вы можете создавать URL с помощью ISBN, который возьмет Вас прямо к книжной странице детали. Та страница не так очень полезна, потому что это - все еще очистка HTML для получения данных, но у них есть ссылка для загрузки книжных данных в паре "стандартных" форматов.
, Например, их демонстрационная книга: http://www.worldcat.org/isbn/9780060817084 Имеет ссылку на загрузку формата "Примечания" http://www.worldcat.org/oclc/123348009?page=endnote&client=worldcat.org-detailed_record , и можно получить данные из того файла очень легко. Это связано от их собственного числа OCLC, не ISBN, но царапанья для преобразования, который не тверд, и у них может все же быть хороший интерфейс, чтобы сделать это.
6 ответов
update - предупреждение: есть способ получше, не используйте его, вместо этого см. Ответ Итана!
Я бы не сказал, что есть веская причина избегать Response.End . Желание избежать затрат на ThreadAbortException, позволяя циклу запроса страницы продолжаться и заставляя его выполнять дополнительную работу, в которой нет необходимости, кажется неправильным.
ThreadAbortException - это особый тип исключения, предназначенный для остановки выполнения потока (оно автоматически генерируется повторно, даже если оно было обнаружено). Тем не менее, есть несколько сценариев, в которых он может нанести вред (см. Содержимое сообщества, добавленное в конце ThreadAbortException ).
Если вы не находитесь в одном из этих сценариев, вам следует придерживаться Response.End. Обратите внимание, что в некоторых случаях используйте SuppressContent & Response.End,
Это очень распространенный вопрос. И почти всегда ошибочно вызывать что-либо, кроме Response.End () . Вот описание End () из MSDN:
Отправляет весь текущий буферизованный вывод клиенту, останавливает выполнение страницы и вызывает событие EndRequest.
Кажется, это именно то, что ты хочешь сделать. И вы заметите в последней части, что он вызывает событие EndRequest. Это означает, что после вызова End () все данные передаются клиенту, которые были записаны до End (), сокет закрывается,
Насколько я понимаю, код при отражении HttpResponse с использованием подхода Flush / SuppressContent сделает вас уязвимыми для кода, пытающегося внести изменения в заголовок после сброса. Изменение заголовка после сброса вызовет исключение HttpException.
Я бы использовал Response.End (), чтобы быть абсолютно уверенным, что ничто другое не может помешать ответу.
Если вы хотите продолжить выполнение, но также закоротите конвейер http рассмотрите возможность использования Response.Flush () и HttpContext.Current.ApplicationInstance.CompleteRequest (), как Response.End (), когда контекст не находится в периоде отмены.
Вы уверены, что стратегия дизайна верна? Какую предварительную обработку вы можете сделать, чтобы гарантировать отправку правильных заголовков, а затем придерживаться ее, пока сценарий не выполнит свои задачи?
Что, если после вызова Response.SuppressContent = true ваша страница продолжит вносить изменения в запись в базе данных?
В конце концов я нашел простое решение для использования Response.End () без получения исключения ThreadAbortException.
Response.Flush();
Response.End();
Исходя из моего исходного вопроса, я всегда пытался ПРОСТО использовать Response.End () после отправка некоторого контента в поток ответов.
Похоже, что если при выполнении Response.End () есть не очищенное содержимое, вы получите исключение ThreadAbortException. Выполняя сброс непосредственно перед концом, исключение ThreadAbortException на самом деле не генерируется.
Кажется, все работает отлично - теперь, когда я использую Response.End, исключение ThreadAbortException не генерируется