EOF excption in HTTP 1.1 server interaction

Tue May 15 18:44:08 UTC 2018

Thanks for the clarification; as I mentioned, I tried a number of
variations, with and without the "excess" empty lines. I also copied the
output from a curl session with a server that provides a successful
interaction with the client (so the content length etc were all correct).
In every case the *send* failed regardless. I'm finding myself inclined to
believe that something about the way the upgrade to 2.0 request is being
handled is relevant. That said, I'm unsure what line endings I'm sending in
my fake server, but I'm running on Linux, not windows (perhaps that's your
point).

So that we can finally put to bed one way or the other the suggestion that
this is the server-side's fault, perhaps you could indicate an exact
(minimal) string, that you believe should work in my fake-server? I'm not
an expert in the HTTP specification, so it could be pretty inefficient to
keep cycling round this loop ;)

On Tue, May 15, 2018 at 12:16 PM Bernd Eckenfels <ecki at zusammenkunft.net>
wrote:

> Your example code writes 2 (emp5) lines more than the Content-Length
> includes. You should also use crlf for the end of http headers (Sample
> works only on Windows)ö
>
> Gruss
> Bernd
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ------------------------------
> *From:* net-dev <net-dev-bounces at openjdk.java.net> on behalf of Simon
> Roberts <simon at dancingcloudservices.com>
> *Sent:* Tuesday, May 15, 2018 7:22:27 PM
> *To:* net-dev at openjdk.java.net
> *Subject:* EOF excption in HTTP 1.1 server interaction
>
> (Added subject line, sorry, not sure how I missed that in the first place!)
>
> I can pretty much confirm this has nothing to do with content length. I
> wrote the code below to allow experimentation and even as it stands, which
> I believe has a correct content length, and a bunch of other stuff removed
> from the response) the client still fails. I also tried it with various
> combinations of the response lines commented out, and all of them present,
> failure every time.
>
> If you'd like to suggest the combination that "should" work, I'd be happy
> to try it of course.
>
> public final class Main {
>   public static final String[] response = {
>       "HTTP/1.1 200 OK",
> //      "X-Powered-By: Express",
> //      "Content-Type: text/html; charset=utf-8",
>       "Content-Length: 58",
> //      "ETag: W/\"3a-EwoPOQKsJivlqZA3z/ulngzMv9U\"",
> //      "Date: Tue, 15 May 2018 00:18:47 GMT",
> //      "Connection: keep-alive",
>       "",
>       "<html><body><h1>Heading</h1><p>Some Text</p></body></html>",
>       "",
>       ""
>   };
>
>   public static void main(String[] args) throws Throwable {
>     var ss = new ServerSocket(8080);
>     var s = ss.accept();
>     var in = new BufferedReader(new InputStreamReader(s.getInputStream()));
>     String line;
>     while ((line = in.readLine()) != null) {
>       System.out.println("< " + line);
>       if ("".equals(line)) break;
>     }
>     var out = new PrintWriter(new OutputStreamWriter(s.getOutputStream()));
>     for (var st : response) {
>       out.println(st);
>       System.out.println("> " + st);
>     }
>     out.flush();
>     s.close();
>
>   }
> }
>
>
> On Tue, May 15, 2018 at 9:46 AM Chris Hegarty <chris.hegarty at oracle.com>
> wrote:
>
>> Simon,
>>
>> Only a partial reply, I’ll reply with other details later.
>>
>> > On 15 May 2018, at 16:10, Simon Roberts <simon at dancingcloudservices.com>
>> wrote:
>> >
>> > If I understand you correctly, you are saying that the "simple" version
>> of the code-code by the way that the project's main web page presents as
>> it's first example--is so simple that it's actually unusable in any
>> production scenario.
>>
>> That is not what I am saying. What I am saying is that the String handler
>> is a convenience handler that buffers all the response data and returns it
>> once decoded. In some circumstances it is just not possible to return, as a
>> String, the response data, if the server behaves incorrectly. In the
>> scenario you are encountering it appears that the server is returning too
>> little data. It may not be possible to always decode this partial data. And
>> even if you do decode this partial data, something further up the stack is
>> likely to fail, if parsing JSON for example.
>>
>> My point is that if you want fault tolerance in the case of a misbehaving
>> server there are other ways to achieve that.
>>
>> > I know I cannot use code for production that fails to read any data
>> from a (presumably) merely mis-configured server (a server from which all
>> other tools successfully read data.
>>
>> What do you hope to do with partial data read from the server? If it’s
>> JSON can you decode it, or a gif can you display it?
>>
>> > Did I interpret correctly, or did I miss something? If correctly, I'd
>> be surprised if that doesn't strike you as sub-optimal to the point your
>> pride in your work would want to make it more usable.
>>
>> We do have pride in our work. I am engaging here to try to help you.
>>
>> > It doesn't seem inappropriate to report a "warning" situation using an
>> exception? Would not an aggregate return that includes data, headers,
>> status code, ... and warnings be more helpful in this case?
>>
>> There are other ways to achieve that, but IMO doing so for the String
>> handler would not be helpful to the vast majority of Java developers, that
>> would not check the carried warning.
>>
>> > Mis-configured servers (assuming that's the cause) are not uncommon
>> around the web.
>>
>> Sure, but many clients will not be able to operate correctly with such,
>> it’s a matter of where and how they fail.
>>
>> > But perhaps more importantly, whatever the problem is, it is not fixed
>> by your code. The error is actually thrown by the *send* call, as I've now
>> determined as a result of trying your code. (I modified it very slightly so
>> as to complete it, and catch the exception.)
>>
>> D’oh! Apologies, that’s what I get for sending something without testing
>> it more carefully, but you seem to have gotten past it.
>>
>> -Chris
>
>
>
> --
> Simon Roberts
> (303) 249 3613
>
>

-- 
Simon Roberts
(303) 249 3613
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20180515/d19a22e4/attachment-0001.html>