Установите свойство ContentLength перед вызовом GetRequestStream (или BeginGetRequestStream) и затем запишите меньшее количество байтов в этот поток. ContentLength будет выдавать, если вы попытаетесь установить его после получения потока запросов. Если вы не установите ContentLength, HttpWebRequest будет буферизовывать заголовки до тех пор, пока поток не будет закрыт, чтобы он мог соответствующим образом установить ContentLength (альтернативно, вы можете использовать SendChunked, но здесь это не будет работать). Если вы хотите получить максимальный контроль над этим, создайте один или два запроса вручную, а затем откройте сокет для порта 80 на сервере и запишите запрос в поток TCP, а затем прочитайте ответ и проверьте соединение, чтобы увидеть, было ли оно закрыто. .
ОДНАКО: я не думаю, что этот тест - хорошая идея. Вот проблема:
Клиент отправляет запрос на сервер. Он утверждает, что содержимое будет 100 байтов. Затем он отправляет 90 байтов, а затем просто прекращает отправку, оставляя соединение открытым. Сервер читает 90 байтов, а затем ожидает остальных, поскольку клиент сказал, что будет отправлено 100 байтов. Теперь Клиент отправляет второй запрос. Что будет делать сервер с первыми 10 байтами нового запроса?
Ответ заключается в том, что сервер предположит, что эти байты были частью предыдущего запроса, и обработает их как таковые, а затем начнет читать «новый» запрос через 10 байт после его запуска, что, очевидно, приведет к неправильным заголовкам. Серверу это не понравится, поэтому он отправит ошибку 4xx, а затем закроет соединение. Причина, по которой он закрывает соединение, состоит в том, что теперь у него нет возможности узнать, что означают отправляемые ему данные, и нет способа восстановить. Кроме того, закрытие соединения не будет изящным, оно будет внезапным, и запрос HttpWebRequest на другом конце, который отправляет второй запрос (или третий или четвертый, если они поставлены в очередь), вызовет исключение WebException, сообщающее, что лежащее в основе соединение было закрыто, и вам остается только догадываться, почему.
Это то же поведение вызывает закрытие соединения с заголовком Expect 100-continue, и сервер возвращает 100-continue, за которым следует 4xx, например, когда требуется Auth. Несмотря на то, что он отклонил запрос, он все равно ДОЛЖЕН предположить, что следующие байты являются частью того же запроса, так как он принял на себя обязательство получить эти байты, отправив продолжение 100. Если он не будет обслуживать этот запрос или если клиент захочет отменить запрос и отправить новый (предположительно с учетными данными аутентификации), он должен закрыть соединение и открыть новое.
Наконец, тестирование исключения EndOfStreamException из сетевого потока с использованием TCP вообще не имеет для меня никакого смысла. TCP не помечает «конец» потока, он просто продолжает посылать данные так, как они записаны в сокет. Для этого нет «EOF» и нет способа определить, все ли данные были переданы, если вы не знаете, сколько данных ожидать. TCP не имеет «конца» своего потока, если соединение не закрыто, в этом случае вы получите исключение WebException или SocketException в зависимости от того, где в стеке вы работаете. Любые ошибки передачи в протоколе рассматриваются в winsock. Если данные больше не отправляются, один конец соединения в конечном итоге отправит подтверждение активности другому, чтобы убедиться, что соединение все еще действительно открыто, и один хост не просто отбросил его. Если время активности активности истекло, соединение будет закрыто, и вы можете получить исключение WebException при следующем чтении с него. Учитывая, как все это работает, я просто не понимаю, как вы собираетесь извлечь какую-либо выгоду из этого теста. Вам гораздо лучше просто отправлять неправильно сформированные запросы и следить за тем, чтобы ошибки обрабатывались соответствующим образом, а соответствующее сообщение 4xx отправлялось обратно клиенту, а соединение закрывалось правильно.