"not enough bytes" when connecting to `https://`-uri site

[hvr]

Performing a simple simpleHttp "https://t4a.box-world.org/" fails with

ParseError {errorContexts = ["HTTP status line","demandInput"], errorMessage = "not enough bytes"}

I have no idea why this fails, as curl(1) or Python's httplib work just fine

[vincenthz]

Thanks hvr. I've just fixed the issue in tls-0.4.1 (and tls-0.5.1). can you upgrade to tls-0.4.1 and re-test ?

[hvr]

I upgraded and rebuild http-enumerator, but I still get that exception :-/

what did you change in 0.4.1? I didn't any commit in the hs-tls github repo...

[hvr]

...and I closed this issue by accident and now I don't know how to reopen it :-(

[snoyberg]

I've reopened the ticket. Sorry for my earlier comment, I hadn't realized that Vincent had already responded to this issue.

[vincenthz]

@hvr: sorry, i had forgotten to push; it's now completly uptodate. the issue was that tls was not properly handling multiple data sub packet in one packet (which is perfectly reasonable TLS protocol).

@snoyberg: i think i solved the tls issue already. there's still an issue because the enumerator thinks empty data = end of connection i think, and indeed when i try the following url, the first packet received is empty data. I replaced the following piece in sslClientConn and it works as expected:

 return ConnInfo
    { connRead = recvD istate
    , connWrite = liftIO . sendData istate . L.fromChunks
    , connClose = liftIO $ bye istate >> hClose h
    }
where
  recvD istate = do
    x <- liftIO $ recvData istate
    if L.null x
        then recvD istate
        else return $ L.toChunks x

[snoyberg]

For HTTP 1.0 responses without a content-length, http-enumerator needs to know that it has reached the end of the stream. How can I test for that?

[snoyberg]

OK, patch applied and 0.5.1 is released.

[hvr]

thx, seems to work for me now :-)

[vincenthz]

oops, saw your question only now. I think the API is not very handling the end of stream very well at the moment, however an empty packet would not signify the end of stream with tls, it would be more about keep alive. The end of stream would be notify by the other side properly (the closing alert that is send by the function bye).

I need to work on this, but i think you'll likely to get an IO exception for EOF with current code.