Как настроить HTTPServer на использование длины содержимого, а не на передачу кодировки: фрагментировано?

Я использую объект HTTP-сервера Java с веб-службой, реализованной WebServiceProvider. Я вижу, что независимо от запроса клиента ответ разбивается на части, и мне нужно, чтобы он был с длиной содержимого. так что я предполагаю, что проблема в сервере, а не в провайдере веб-сервера, верно? и как я могу настроить заголовок http, чтобы использовать длину содержимого, а не разбивать его на части?

    HttpServer m_server = HttpServer.create();
    Endpoint ep= Endpoint.create(new ep());
    HttpContext epContext = m_server.createContext("/DownloadFile");
    ep.publish(downloadFileContext);

java chunked content-length com.sun.net.httpserver
person Sophie    schedule 02.08.2011    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Я предполагаю, что вы говорите о _ 1_ HTTPServer. Я также предполагаю, что вы подключаете сервер к службе с помощью вызова _ 2_, используя поставщика услуг, поддерживающего HTTPServer.

Ключ находится в _ 3_:

Если параметр длины ответа больше нуля, это указывает точное количество байтов для отправки, и приложение должно отправить именно этот объем данных. Если параметр длины ответа равен нулю, то используется кодирование передачи по частям и может быть отправлен произвольный объем данных. Приложение завершает тело ответа, закрывая OutputStream.

Итак, пока обработчик передает положительное значение для responseLength, используется Content-Length. Конечно, для этого он должен заранее знать, сколько данных он собирается отправить, чего вполне может не быть. Боюсь, это зависит от реализации привязки или нет. Я не верю, что это стандартизовано - действительно, я не верю, что WebServiceProvider / HTTPServer вообще стандартизирован.

Однако, даже если ваш провайдер отказывается сотрудничать, у вас есть выход: напишите Фильтр, который добавляет буферизацию, и добавить его в HttpContext, который вы используете для публикации службы. Я думаю, что для этого вам нужно будет написать реализацию HttpExchange, который буферизует записанные в него данные, передает их по цепочке фильтров, чтобы обработчик мог записать свой ответ, а затем, когда он вернется, напишите буферизованный контент, устанавливая responseLength, когда он это делает.

person Tom Anderson    schedule 02.08.2011
comment
Привет. это звучит правильно, но у меня есть веб-службы, которые публикуются как конечные точки, поэтому некоторый контекст на сервере, поэтому я фактически не управляю какими-либо ответами через сам сервер, ответ отправляется из веб-службы. - person Sophie; 03.08.2011
comment
@ Софи: Я не понимаю, извини. Вы хотите сказать, что не контролируете код, который публикует веб-службы на HTTPServer? Не могли бы вы отредактировать свои вопросы, указав более подробную информацию о том, как работает ваш код, и какие его части вы можете изменить? - person Tom Anderson; 03.08.2011
comment
я добавил пример кода. ep - это веб-сервис, который у меня есть. поэтому, когда клиент выполняет ip_add / DownloadFile, он переходит в мою веб-службу. Я также знаю длину отправляемых данных. - person Sophie; 03.08.2011
comment
Понятно (хотя я предполагаю, что «downloadFileContext» должен быть «epContext»). К сожалению, хотя вы можете знать длину ответа, привязка веб-службы не знает, и это привязка, которая взаимодействует с HttpExchange. Но поскольку у вас есть доступ к HttpContext, вы можете написать фильтр, который буферизует вывод, как я объяснил, и добавить его в контекст (epContext.getFilters().add(new BufferingFilter())). В качестве альтернативы вы можете написать фильтр, который устанавливает длину ответа и не выполняет буферизацию, но это вызовет ошибку, если вы ошиблись в длине, что рискованно. - person Tom Anderson; 03.08.2011
comment
Мне удалось получить httpExchnage из WebServiceContext и вызвать на нем HttpExchange.sendResponseHeaders. Итак, теперь я вижу Content-Length в HTTP-сообщении, но само сообщение не получено клиентом - полезная нагрузка не отправляется. любые идеи, как я могу продолжить? - person Sophie; 03.08.2011