| These are problems known to exist at the time of this release. Feel free to |
| join in and help us correct one or more of these! Also be sure to check the |
| changelog of the current development status, as one or more of these problems |
| may have been fixed since this was written! |
| |
| * LDAP output is garbled. Hardly anyone seems to care about LDAP functionality |
| in curl/libcurl why this report has been closed and set to be solved later. |
| If you feel this is something you want fixed, get in touch and we'll start |
| working. |
| http://sourceforge.net/tracker/index.php?func=detail&aid=735752&group_id=976&atid=100976 |
| |
| * IPv6 support on AIX 4.3.3 doesn't work due to a missing sockaddr_storage |
| struct. It has been reported to work on AIX 5.1 though. |
| |
| * Running 'make test' on Mac OS X gives 4 errors. This seems to be related |
| to some kind of libtool problem: |
| http://curl.haxx.se/mail/archive-2002-03/0029.html and |
| http://curl.haxx.se/mail/archive-2002-03/0033.html |
| |
| * libcurl does not deal nicely with files larger than 2GB |
| |
| * GOPHER transfers seem broken |
| |
| * configure --disable-http is not fully supported. All other protocols seem |
| to work to disable. |
| |
| * The -m parameter does not work when using telnet with curl on Windows. |
| |
| * If a HTTP server responds to a HEAD request and includes a body (thus |
| violating the RFC2616), curl won't wait to read the response but just stop |
| reading and return back. If a second request (let's assume a GET) is then |
| immediately made to the same server again, the connection will be re-used |
| fine of course, and the second request will be sent off but when the |
| response is to get read, the previous response-body is what curl will read |
| and havoc is what happens. |
| More details on this is found in this libcurl mailing list thread: |
| http://curl.haxx.se/mail/lib-2002-08/0000.html |
| |
| ------------------------------------------------------------------------------ |
| |
| Q: My program blows up when I run lots of curl_easy_perform() calls on a |
| single thread |
| Q: My program dies when a single thread re-enters the win32 select() call |
| via curl_easy_perform() |
| Q: --- add your own flavour here --- |
| |
| Single Threaded Re-Entracy |
| -------------------------- |
| |
| There is a glitch / trick to using cURL on Win32 related to re-entrancy. |
| This experience was gained on verion 7.9.4 using Windows NT SP3 in a banking |
| environment (just in case you wanted to know). |
| |
| If you have already called curl_easy_perform(), and *somehow* you cause your |
| single thread of execution to make another call to curl_easy_perform() - the |
| windows socket() call used to create a new socket for the second connection |
| can return with 10044 / 10043 error codes. |
| |
| The WSA errors we experienced are: |
| WSAEPROTONOSUPPORT |
| (10043) |
| Protocol not supported. |
| The requested protocol has not been configured into the system, or no |
| implementation for it exists. For example, a socket call requests a |
| SOCK_DGRAM socket, but specifies a stream protocol. |
| |
| WSAESOCKTNOSUPPORT |
| (10044) |
| Socket type not supported. |
| The support for the specified socket type does not exist in this address |
| family. For example, the optional type SOCK_RAW might be selected in a |
| socket call, and the implementation does not support SOCK_RAW sockets at |
| all. |
| |
| We have experienced this by creating a timer that ticks every 20ms, and on |
| the tick making a curl_easy_perform() call. The call usually completed in |
| about 300ms. And we expected (before this test) that the timer would NOT be |
| fired during a call to curl_easy_perform(), howvever, while the first |
| curl_easy_perform() is running a tick *is* fired by the windows API somehow, |
| and we then call curl_easy_perform() again - thus single threaded |
| re-entrancy is achieved. |
| |
| Notes: |
| * We made sure that a new CURL structure was being used for each |
| curl_easy_perform() request, and that the curl_global_init() had been called |
| beforehand. |
| * I'm happy to answer any questions about this problem to try to track it |
| down. |
| * Once the socket() call started failing, there is no hope - it never works |
| again. |
| * Slowing the timer down to give each request enough time to complete solves |
| this problem completely. |
| |
| If anyone has the source code to the WinNT implementation of socket() and |
| can figure out WHY this can occur, more tracing can be performed. |
| |
| John Clayton <John.Clayton at barclayscapital.com> |