john blair | 1 May 01:12 2009
Picon

Re: fat binary for Mac OSX 10.5.X


Thanks Yang, and Toby. Both methods work fine. 
I ended up using the single pass method. I had to do the following changes:
Changed the contents of include/curl/curlbuild.h to
#ifdef __LP64__
#include "curlbuild64.h"
#else
#include "curlbuild32.h"
#endif

where curlbuild64.h and curlbuild32.h were created by running configure separately for x86_64 and i386
architecture. Also, applied the following patch: 
diff -Naur curl-7.19.4-old/lib/config.h curl-7.19.4/lib/config.h
--- curl-7.19.4-old/lib/config.h        2009-04-30 15:37:28.000000000 -0700
+++ curl-7.19.4/lib/config.h    2009-04-30 15:20:10.000000000 -0700
 <at>  <at>  -848,19 +848,35  <at>  <at> 
 #define SIZEOF_INT 4

 /* The size of `long', as computed by sizeof. */
+#ifdef __LP64__
 #define SIZEOF_LONG 8
+#else /* !__LP64__ */
+#define SIZEOF_LONG 4
+#endif /* __LP64__ */

 /* The size of `off_t', as computed by sizeof. */
 #define SIZEOF_OFF_T 8

 /* The size of `size_t', as computed by sizeof. */
+#ifdef __LP64__
(Continue reading)

David McCreedy | 1 May 01:55 2009
Picon

[PATCH] http.c fix to Curl_proxyCONNECT for non-ASCII platforms.

This patch allows Curl_proxyCONNECT to work on non-ASCII platforms.



Attachment (patch.http.20090430.diff): application/octet-stream, 1300 bytes
David McCreedy | 1 May 02:42 2009
Picon

[PATCH] TPF-platform specific changes to various files

This patch contains various TPF-platform specific changes.

 

A TPF-specific change to include additional header files was made to three header files:

   lib/setup.h, src/setup.h, and tests/libtest/test.h

 

TPF-specific values were added to include/curl/curlbuild.h because TPF does not run configure as part of its Curl build process.

 

And I would like to create sample build files for the TPF platform since it doesn't use the normal Makefiles:

   packages/TPF/curl.mak,

   packages/TPF/maketpf.env_curllib, and

   packages/TPF/maketpf.env_curl

 

Thank you,

 

David McCreedy

Attachment (patch.tpf.20090430.diff): application/octet-stream, 14 KiB
David McCreedy | 1 May 02:49 2009
Picon

[PATCH] transfer.c fixes for CURL_DO_LINEEND_CONV and non-ASCII platform HTTP requests

While testing using the Curl test suite on TPF I uncovered a rather complicated problem:

If the HTTP request headers can't be sent in one system call in http.c's add_buffer_send(), the remaining portion gets sent later by transfer.c.

That causes two problems:

1) On non-ASCII platforms the remaining portion is re-converted (into garbage) if data->set.prefer_ascii is set.

2) On all platforms the line endings are mangled from CRLF to CRCRLF if data->set.crlf or data->set.prefer_ascii are set (depending on the CURL_DO_LINEEND_CONV #define).

This patch addes checks to prevent these problems.

 

Additional changes address two HTTP PUT problems:

1) On non-ASCII platforms not all of the protocol portions of the PUT are being translated to ASCII.

2) On all platforms the line endings of part of the protocol portions are being mangled from CRLF to CRCRLF if data->set.crlf or data->set.prefer_ascii are set (depending on the CURL_DO_LINEEND_CONV #define).

 

Thank you,

 

David McCreedy

 

Attachment (patch.transfer.20090430.diff): application/octet-stream, 7675 bytes
David McCreedy | 1 May 02:53 2009
Picon

[PATCH] Allow Curl test suite test #251 to work if client and server are on different machines

This patch changes tests/ftpserver.pl and tests/runtests.pl to pass the client IP address on FTP Server tests. 

This allows test 251 to function if the script is running on a system where the server and client aren't on the same machine. 

(If they're on the same machine the IP address for the server and client are the same so the test worked fine.)

 

Thanks,

 

David McCreedy

Attachment (patch.runtests.20090430.diff): application/octet-stream, 2771 bytes
David McCreedy | 1 May 03:03 2009
Picon

[PATCH] Allow various Curl test suite tests to work on non-ASCII platforms

The Curl test suite is very useful.

This patch allows various HTTP and FTP tests to work on both ASCII and non-ASCII platforms alike.

 

Changes to tests/data/test508 and test555:

Added a "strippart" section command to remove the carriage return that the CURLOPT_TRANSFERTEXT option adds to the line ending(s) in the POST data.

 

Modification to tests/libtest/lib506.c:

Changed to allow the code to work on non-ASCII platforms.

 

Modificatons to tests/libtest/lib508.c, lib510.c, lib552.c, lib553.c, and lib555.c:

Changed to use the CURLOPT_TRANSFERTEXT option on platforms where CURL_DOES_CONVERSIONS (non-ASCII platforms) so the POST data from the CURLOPT_READFUNCTION will be converted to ASCII.

 

Also added a TPF platform-specific sleep function call to avoid a loop timing dump in lib555.c.

 

Modifications to tests/libtest/lib544.c, lib547.c, and lib554.c:

Changed to use C language escape sequences so that the POST data is defined in ASCII on both ASCII and non-ASCII platforms.

 

Modifications to tests/libtest/lib556.c:

Changed to use C language escape sequences so that the raw HTTP request is defined in ASCII on both ASCII and non-ASCII platforms.

 

Also added a TPF platform-specific sleep function call to avoid a loop timing dump.

 

Thanks,

 

David McCreedy

Attachment (patch.libtest.20090430.diff): application/octet-stream, 12 KiB
Pankaj Kumar Maharana | 1 May 09:48 2009
Picon

Re: HTTP 401- Unauthorized error.

Daniel,

Still it did not solve the issue.. I tried by setting CURLOPT_HTTPAUTH to  CURLAUTH_BASIC. But I found a new use case. The new use case is that if I set CURLAUTH_BASIC with the initial request itself than I did not get any response at all. So I tried setting CURLAUTH_ANY with the initial request. But when I get 401 error than set CURLAUTH_BASIC with the username and password from header callback. Here I observed that the issue of not sending second time is still there with this approach also.

The issue is, with the same handle when i am setting a new username and password than CURL does not send that information to the server. Instead it gives back the response body through write_callback function. I understand that it is not the correct behaviour. If I am setting username and password with the same handle than CURL need to send the info to server and need to call header_callback with the response header. Does the return value of header_callback function keep some impact on this(For not sending the request again)?

What I don’t understand is , is this the curl behaviour or there is some options to set which i am missing.

 

Thanks,

Pankaj

Daniel Stenberg | 1 May 11:39 2009
Picon

Re: HTTP 401- Unauthorized error.

On Fri, 1 May 2009, Pankaj Kumar Maharana wrote:

> Still it did not solve the issue.. I tried by setting CURLOPT_HTTPAUTH to 
> CURLAUTH_BASIC. But I found a new use case. The new use case is that if I 
> set CURLAUTH_BASIC with the initial request itself than I did not get any 
> response at all.

I'd claim that's a flaw in the server end in that case. Or how is this 
libcurl's fault?

> So I tried setting CURLAUTH_ANY with the initial request. But when I get 401 
> error than set CURLAUTH_BASIC with the username and password from header 
> callback. Here I observed that the issue of not sending second time is still 
> there with this approach also.

It's not supposed to. The header callback just brings you the response 
headers, it will not trigger another request even if you alter options. You 
need to do that second request yourself.

> The issue is, with the same handle when i am setting a new username and 
> password than CURL does not send that information to the server. Instead it 
> gives back the response body through write_callback function.

Yes, that's what it is supposed to do. You can of course abort that by 
returning the right code from the write callback.

> I understand that it is not the correct behaviour. If I am setting username 
> and password with the same handle than CURL need to send the info to server 
> and need to call header_callback with the response header.

libcurl doesn't work that way at any time really. It's basically:

  * create handle
  * set options
  * perform request
  * receive data / send data

...and if you then want to alter options, you can of course do this at any 
time during the receiving/sending but they change in the handle and will only 
be used when you (the app) do a subsequent request.

--

-- 

  / daniel.haxx.se

Yang Tse | 1 May 14:47 2009
Picon

Re: [PATCH] TPF-platform specific changes to various files

2009/5/1, David McCreedy wrote:

> This patch contains various TPF-platform specific changes.

Committed with minor changes, see below...

> A TPF-specific change to include additional header files was made to three
> header files:
>
>    lib/setup.h, src/setup.h, and tests/libtest/test.h

The minor changes to this patch have been in the above three files.

> TPF-specific values were added to include/curl/curlbuild.h because TPF does
> not run configure as part of its Curl build process.

Additionally we need to know the data type and size used for the third
argument of getpeername(), this will be used for curl_socklen_t.

If the data type is not a compiler native data type we also need to
know which system header files are required to be included to get its
type definition.

> And I would like to create sample build files for the TPF platform since it
> doesn't use the normal Makefiles:
>
>    packages/TPF/curl.mak,
>    packages/TPF/maketpf.env_curllib, and
>    packages/TPF/maketpf.env_curl

These committed without changes.

--

-- 
-=[Yang]=-

Yang Tse | 1 May 15:01 2009
Picon

Re: [PATCH] http.c fix to Curl_proxyCONNECT for non-ASCII platforms.

2009/5/1, David McCreedy wrote:
>
> This patch allows Curl_proxyCONNECT to work on non-ASCII platforms.

Committed.

Thanks
--

-- 
-=[Yang]=-


Gmane