Wooops, bran failure. JLS 3.10.4 :( Will fix to use \r\n and get back...
On Tue, May 15, 2018 at 1:43 PM Bernd Eckenfels <e...@zusammenkunft.net> wrote: > Try using out.print(st+“\n\r“); instead. (And Account for the extra bytes > in the body as well or output the last string without the EOLs. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > ------------------------------ > *From:* net-dev <net-dev-boun...@openjdk.java.net> on behalf of Simon > Roberts <si...@dancingcloudservices.com> > *Sent:* Tuesday, May 15, 2018 8:44:08 PM > *To:* net-dev@openjdk.java.net > *Subject:* Re: EOF excption in HTTP 1.1 server interaction > > 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 <e...@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-boun...@openjdk.java.net> on behalf of Simon >> Roberts <si...@dancingcloudservices.com> >> *Sent:* Tuesday, May 15, 2018 7:22:27 PM >> *To:* net-dev@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.hega...@oracle.com> >> wrote: >> >>> Simon, >>> >>> Only a partial reply, I’ll reply with other details later. >>> >>> > On 15 May 2018, at 16:10, Simon Roberts < >>> si...@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 > > -- Simon Roberts (303) 249 3613
