Project

General

Profile

Actions
Copy link

Bug #1042

closed

Corrupted Pages on SSL VHosts

Added by Anonymous almost 18 years ago. Updated over 17 years ago.

Status:
Fixed
Priority:
High
Category:
core
Target version:
1.5.0
ASK QUESTIONS IN Forums:

Description

I have some trouble with a SSL VHost. I connected PHP properly via mod_proxy_core but pages over 16300 bytes or sometimes 8100 bytes length are cutted. Often, the server delivers no data (a fully blank site) I got some messages in error log complaining about some SSL-things. I got no SSL errors on client side about handshake failures or something else (Using Firefox) But look for yourself:


network_openssl.c.86: (error) ssl-errors: error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry
network_openssl.c.86: (error) ssl-errors: error:1409F07F:SSL routines:SSL3_WRITE_PENDING:bad write retry
connections.c.595: (error) ++ oops, something went wrong while reading
connections.c.1025: (trace) (error)

There is a second tiny bug too. There are no timestamps in the errorlog anymore.

In Non-SSL mode via port 80, the VHost works perfectly, no errormessages, no corrupted pages.

And by the way:

Lighty is a great webserver application. Very good work !! ;-)

-- eebkiller

Files

network_openssl_return_wait_for_event.patch (510 Bytes) network_openssl_return_wait_for_event.patch return NETWORK_STATUS_WAIT_FOR_EVENT on SSL_ERROR_WANT_WRITE in network_openssl.c -- peterco Anonymous, 2007-03-19 17:19
Actions
Copy link
 #1

Updated by Anonymous over 17 years ago

Hello,

as mentioned before (#1087), I was also hit by this bug. Similar to the bug description above, I received blank pages for proxy responses bigger than an arbitrary size (in my tests, the magic failure limit was about 12500 bytes, depending on the total response size), and this only happened with SSL enabled. However, with the latest revision (svn r1716), not a single error message was logged.

After lots of debugging, I believe to have found the culprit in the network_openssl.c backend.

While processing the chunks in the given chunk queue, the {{{SSL@SSL_get_error@ call may fail at any time, with an error value of {{{SSL@SSL_ERROR_WANT_WRITE@. Regardless of whether the chunk type is {{{MEM@MEM_CHUNK@ (as in the case of mod_proxy_core writing to this backend) or {{{FILE@FILE_CHUNK@, the chunk processing loop is interrupted, and the variable chunk_finished contains the value 0. Despite the failure to write all chunks, the function then returns {{{NETWORK@NETWORK_STATUS_SUCCESS@. This effectively causes the non-written chunks to be lost.

The simple solution is therefore to {{{return NETWORK@return NETWORK_STATUS_WAIT_FOR_EVENT@ in case of receiving the error {{{SSL@SSL_ERROR_WANT_WRITE@. (Later, I discovered that solving this problem could have been much easier, had I taken a prior look at some of the newer backends, such as network_linux_aio.c...)

I have included an appropriate patch below, which also purges the unused variable {{{chunks@chunks_written@.

Regards,
Peter.

-- peterco

Actions
Copy link
 #2

Updated by Anonymous over 17 years ago

(I meant to say that the '''{{{SSL_write}}}''' call may fail at any time, of course.)

-- peterco

Actions
Copy link
 #3

Updated by Anonymous over 17 years ago

I ran into this issue several times a day while testing the 1.5 series and SVN trunk. I haven't had any problems since applying Peter's patch, about a week ago.

-- Mike Owens

Actions
Copy link
 #4

Updated by Anonymous over 17 years ago

Thanks a lot !

It appears, that my problem is solved too.

-- eebkiller

Actions
Copy link
 #5

Updated by jan over 17 years ago

  • Status changed from New to Fixed
  • Resolution set to fixed

yep, network_openssl.c wasn't fully ported to the new backend interface.

The patch is applied in r1796

Actions
Copy link

Also available in: Atom