[JAVA] available() van HttpsURLConnection altijd 0

Pagina: 1
Acties:

  • JnX
  • Registratie: Februari 2001
  • Laatst online: 18-01 22:08
Ik heb op een webserver een PHP script dat data uitspuugd via de print() methode. Het script leest deze data op zijn beurt weer uit een socket verbinding met een JAVA applicatie op de server. Het script staat in een https omgeving.

Vanuit een JAVA applicatie wil ik de data die het script print, uitlezen. Hiervoor open ik een HttpsURLConnection op het adres van het PHP script. Tot zover werkt het allemaal: ik kan een verbinding maken op het script, dit kan ik controleren op de server.

Van deze connectie wil ik de InputStream gebruiken om de data uit te lezen. Het probleem treedt op als ik van deze stream het aantal bytes wil opvragen dat uitgelezen kan worden, met de methode available(). Deze geeft altijd 0 terug. Wanneer ik het PHP script in een 'gewone' http omgeving plaats werkt het echter wel.

Ik heb verschillende opties van de HttpsURLConnection geprobeerd, zonder resultaat. Ik heb ook al geprobeerd om de methode getContentLength() van de HttpsURLConnection te gebruiken, deze geeft altijd -1 terug.

De code:
Java:
1
2
3
4
5
6
7
URL input_url = new URL("https://www.bla.com/bla.php");
HttpsURLConnection input = (HttpsURLConnection) input_url.openConnection();
input.setUseCaches(false);
input.setAllowUserInteraction(true); 
input.setDoInput(true);

DataInputStream input_stream = new DataInputStream(new BufferedInputStream(input.getInputStream()));

  • Kwistnix
  • Registratie: Juni 2001
  • Laatst online: 09-04 20:43

  • JnX
  • Registratie: Februari 2001
  • Laatst online: 18-01 22:08
Bedankt voor de link, maar deze had ik al gevonden en geprobeerd :)

Ik ben er inmiddels achter gekomen dat het uitlezen van data van de InputStream wel werkt zonder de available methode:

Java:
1
2
3
4
while ((b = input_stream.read()) != -1)
{
...
}


Ik wil alleen liever gebruik maken met de available() methode om al 'pollend' te kijken of er data is. Ik heb dan meer controle over het uitlezen en blijf niet vastzitten in een geblokkeerde read(). Is dit soms een bug in de available() methode op een HttpsURLConnection of doe ik nog iets verkeerd?

  • Kwistnix
  • Registratie: Juni 2001
  • Laatst online: 09-04 20:43
Implementation Note: Due to the complexity of the SSL and TLS protocols, it is difficult to predict whether incoming bytes on a connection are handshake or application data, and how that data might affect the current connection state (even causing the process to block). In the Sun JSSE implementation, the available() method on the object obtained by SSLSocket.getInputStream() returns a count of the number of application data bytes successfully decrypted from the SSL connection but not yet read by the application.
Bron: http://java.sun.com/j2se/...ty/jsse/JSSERefGuide.html
(Index: Key Classes -> Core Classes and Interfaces -> SSLSocket and SSLServerSocket Classes)


Ik denk dat het daar fout gaat, omdat ie geen bytes kan decrypten en available() daarom dus resultaat 0 geeft.

[ Voor 4% gewijzigd door Kwistnix op 21-02-2006 15:43 ]


  • Standeman
  • Registratie: November 2000
  • Nu online

Standeman

Prutser 1e klasse

Heb je het certificaat met je keytool geimporteerd in je cacert? Dat kan nog wel eens wat uitmaken.. Wanneer je server niet als trusted wordt aangemerkt door je VM krijg je volgens mij namelijk ook geen data binnen..

(hoewel ik niet zeker weet of dat voor Https ook nodig is, met SSLSocket iig wel).

The ships hung in the sky in much the same way that bricks don’t.


  • JnX
  • Registratie: Februari 2001
  • Laatst online: 18-01 22:08
FallenAngel666 schreef op dinsdag 21 februari 2006 @ 15:34:
[...]


Bron: http://java.sun.com/j2se/...ty/jsse/JSSERefGuide.html
(Index: Key Classes -> Core Classes and Interfaces -> SSLSocket and SSLServerSocket Classes)


Ik denk dat het daar fout gaat, omdat ie geen bytes kan decrypten en available() daarom dus resultaat 0 geeft.
Dat zal het zijn inderdaad, bedankt voor je hulp! Erg jammer dat het niet kan werken, ik zal naar andere oplossingen moeten zoeken.
Pagina: 1