cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: TLS security in Curl

From: amit paliwal <amit.ambitions_at_gmail.com>
Date: Wed, 5 Jan 2011 11:12:00 -0500

Can you all please find 2 mins and have a look on:

http://today.java.net/article/2010/03/31/html5-server-push-technologies-part-1

and please search for "In practice, two popular strategies has been
established. With *long-polling"

@Daniel, it also referes to what you said, but that comes as "long polling"
and then they describe how response stream is kept open to allow server to
push events. My words might eb confusing so I though of providing this link
that expresses what I need.

Now, is it possible to achieve this?

*
On Wed, Jan 5, 2011 at 10:57 AM, amit paliwal <amit.ambitions_at_gmail.com>wrote:

>
>
> On Wed, Jan 5, 2011 at 10:36 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
>> On Wed, 5 Jan 2011, amit paliwal wrote:
>>
>> I assume you're still on your quest to work with those server-sent events?
>
>
> Yes :) and i am sorry to still bother you all with this, but I know you
> people are best in providing this information and I appreciate your time and
> concern.
>
>>
>>
>> The thing is, before using curl_easy_perform() to send HTTP GET and
>>> getting
>>> HTTP response, I need to block on some message from Server.
>>>
>>
>> Yes, but libcurl already does that by itself. When you send the proper
>> requeste to the server, the server will simply not respond at once and
>> libcurl will sit waiting for it. That's the entire concept of SSE and if the
>> server doesn't do that then you didn't send the correct request or the
>> server is broken.
>
>
> You are right, but architecture is a bit different for me. I can keep on
> receiving SSE from server (for idempotent messages, one those does not need
> to have response messages, for e.g. HTTP GET is considered as an idempotent
> message)
>
>>
>>
>> But I think there is no provision to get block before sending HTTP GET by
>>> curl_easy_perform()
>>>
>>
>> If you really want a block before GET you can use sleep() before you
>> invoke curl_easy_perform...
>
>
> But I just dont need to block only but to receive data also, and then
> process that data and after that use curl_easy_perform() to finish one round
> of operation. That is why I though of using select() and recv(). I will not
> do it on separate socket fd, but I will get this socket fd from curl itself
> and use it on select() and recv() and then call curl_easy_perform(). Is it
> invalid to do it?
>
>>
>>
>> 1) use typical OS calls, for e.g. select() followed by recv() to first
>>> ait and then use curl_easy_perform().
>>>
>>
>> No you can't. curl_easy_perform() will set up its own connection/socket
>> and not use the one you used with select() or recv().
>>
>>
>> 2) use CONNECT_ONLY and use curl_easy_send() and curl_easy_recv() to
>>> implement it in the way I need.
>>>
>>
>> Yes, but if the server doesn't wait like I mentioned above it doesn't
>> matter if libcurl returns immediately or if your code does it, the error
>> would still be the same: the one I mentioned above.
>>
>> But I thought Curl can still handle TLS authentication while sending and
>>> receiving from network, even if i use curl_easy_send() and curl_easy_recv().
>>>
>>
>> It does. But the moment you curl_easy_send() or curl_easy_recv() you've
>> abandoned all other protocol support libcurl can offer and you are entirely
>> on your own. IMHO, doing that with a plain HTTP based protocol is unwise.
>>
>
> I agree and in fact it is my main concern here. I need curl to handle http
> and TLS on behalf of me, and as you mentioned it can handle TLS but not HTTP
> if I do proprietary stuff.
>
>>
>> --
>>
>> / daniel.haxx.se
>>
>> -------------------------------------------------------------------
>> List admin: http://cool.haxx.se/list/listinfo/curl-library
>> Etiquette: http://curl.haxx.se/mail/etiquette.html
>>
>
>

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-01-05