Re: HTTP compliance in sendsms (Was: anyone using mutli-cast GET requests)

2002-01-15 Thread Tuomas Luttinen

Stipe Tolj wrote:

> Oded Arbel wrote:

>>Speaking of sendsms' HTTP interface - I've noticed that sendsms doesn't
>>honor the 'Connection: close' header and always use keep-alive. can that be
>>fixed, please ?
 
> I had a look in gwlib/http.c:899 where the following is inside
> handle_transaction():

> [...]
> h = http_header_find_first(trans->response->headers,
> "Connection");
> if (h != NULL && octstr_compare(h, octstr_imm("close")) == 0)
>   trans->persistent = 0;
> octstr_destroy(h);

> #if 1 /* Reuse enabled again, let's see if anyone complains... */
> if (trans->persistent)
> conn_pool_put(trans->conn, trans->host, trans->port);
> else
> #endif
>   conn_destroy(trans->conn);
> [...]

> this seems to honor the "Connection: close" statement, didn't it?!


Yes, the client side is ok. The server side then...

I made a patch that adds a persistency value into the client object that 
the server side uses to store the information about the client. This 
value is added with a function with these rules:

HTTP version 1.0 => non-persistent connection
HTTP version 1.0 + Connection: keep-alive => persistent connection

HTTP version 1.1 => persistent connection
HTTP version 1.1 + Connection: close => non-persistent connection

The outgoing headers are checked too, so if the server sends out 
"Connection: close", the connection is changed to non-persistent.


> Can you describe how we can reproduce the effect you see, so that we
> may analyze ourselfs?!


My problem with the smsc_http was introduced with a nonkannel HTTP 1.1 
client, that kept posting sms:es in through different connections and 
Kannel then kept these connections open so long that idle connections 
built up to a point where the sockets run out.

Now the code dealing with this client in the smsc_http.c adds this 
"Connection: close" header and the HTTP server then knows to hangup the 
connection after replying about the sent sms.

So, if no-one opposes, I'll add this patch into the CVS.


-- 
Tuomas Luttinen
 Application Developer -- Reach U
 **


Index: gwlib/http.c
===
RCS file: /home/cvs/gateway/gwlib/http.c,v
retrieving revision 1.156
diff -c -r1.156 http.c
*** gwlib/http.c2001/12/21 01:55:50 1.156
--- gwlib/http.c2002/01/15 11:27:15
***
*** 989,995 
  {
  Octstr *prefix, *prefix_https;
  long prefix_len;
! int host_len, colon, slash, at, auth_sep;
  
  prefix = octstr_imm("http://";);
  prefix_https = octstr_imm("https://";);
--- 989,995 
  {
  Octstr *prefix, *prefix_https;
  long prefix_len;
! int host_len, colon, slash, at, auth_sep = -1;
  
  prefix = octstr_imm("http://";);
  prefix_https = octstr_imm("https://";);
***
*** 1362,1367 
--- 1362,1368 
  int method;  /* HTTP_METHOD_ value */
  Octstr *url;
  int use_version_1_0;
+ int persistent_conn;
  HTTPEntity *request;
  };
  
***
*** 1385,1390 
--- 1386,1392 
  p->state = reading_request_line;
  p->url = NULL;
  p->use_version_1_0 = 0;
+ p->persistent_conn = 1;
  p->request = NULL;
  return p;
  }
***
*** 1420,1425 
--- 1422,1452 
  
  
  /*
+  * Checks whether the client connection is meant to be persistent or not.
+  * Returns 1 for true, 0 for false.
+  */
+ 
+ static int client_is_persistent(List *headers, int use_version_1_0)
+ {
+ Octstr *h = http_header_find_first(headers, "Connection");
+ 
+ if (h == NULL) {
+   return !use_version_1_0;
+ } else {
+ if (use_version_1_0) {
+   if (octstr_compare(h, octstr_imm("keep-alive")) == 0)
+   return 1;
+   else
+   return 0;
+   } else if (octstr_compare(h, octstr_imm("close")) == 0)
+   return 0;
+ }
+ 
+ return 1;
+ }
+ 
+ 
+ /*
   * Port specific lists of clients with requests.
   */
  
***
*** 1644,1650 
if (conn_outbuf_len(conn) > 0)
return;
/* Reply has been sent completely */
!   if (client->use_version_1_0) {
client_destroy(client);
return;
}
--- 1671,1677 
if (conn_outbuf_len(conn) > 0)
return;
/* Reply has been sent completely */
!   if (!client->persistent_conn) {
client_destroy(client);
return;
}
***
*** 1903,1908 
--- 1930,1938 
octstr_destroy(*body);
*body = NULL;
  }
+ 
+ client->persistent_conn = client_is_persistent(client->request->headers,
+  client->use_version_1_0);
  
  client->url = NULL;
  client->request->headers = NULL;
***
*** 1919,1931 
  {
  Octstr *response;
  long i;
! int ret;
  
  if (c

Re: HTTP compliance in sendsms (Was: anyone using mutli-cast GET requests)

2002-01-03 Thread Stipe Tolj

Oded Arbel wrote:
> 
> Speaking of sendsms' HTTP interface - I've noticed that sendsms doesn't
> honor the 'Connection: close' header and always use keep-alive. can that be
> fixed, please ?

I had a look in gwlib/http.c:899 where the following is inside
handle_transaction():

[...]
h = http_header_find_first(trans->response->headers,
"Connection");
if (h != NULL && octstr_compare(h, octstr_imm("close")) == 0)
trans->persistent = 0;
octstr_destroy(h);

#if 1 /* Reuse enabled again, let's see if anyone complains... */
if (trans->persistent)
conn_pool_put(trans->conn, trans->host, trans->port);
else
#endif
conn_destroy(trans->conn);
[...]

this seems to honor the "Connection: close" statement, didn't it?!

Can you describe how we can reproduce the effect you see, so that we
may analyze ourselfs?!

Stipe

[EMAIL PROTECTED]
---
Wapme Systems AG

Münsterstr. 248
40470 Düsseldorf

Tel: +49-211-74845-0
Fax: +49-211-74845-299

E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are




Re: anyone using mutli-cast GET requests

2002-01-02 Thread Stipe Tolj

> Yes, i'm using this. IT works with CIMD2 at least.

so where is the splitting and looping of the single receiver number of
the "to" GET variable implemented? In smsc_cimd2.c?

Is the code within the current cvs tree or have you an own version?

Stipe

[EMAIL PROTECTED]
---
Wapme Systems AG

Münsterstr. 248
40470 Düsseldorf

Tel: +49-211-74845-0
Fax: +49-211-74845-299

E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are




Re: anyone using mutli-cast GET requests

2002-01-02 Thread Stefan Cars

Yes, i'm using this. IT works with CIMD2 at least.

-
Stefan Cars
CTO
Globalwire Communications
Phone: +46 18 10 79 50
Mobile(UK): +44 788 061 36 69
Mobile(SE): +46 708 44 36 00

On Wed, 2 Jan 2002, Stipe Tolj wrote:

> Stefan Cars wrote:
> >
> > What do you meanwith multi-cast GET ?
>
> the user guide states at
> http://www.kannel.3glab.org/download/kannel-userguide-snapshot/userguide.html#AEN2521
>
> that the "to=" argument may contain multiple receivers, but I can't
> see any implementation of this is the code?!
>
> I'm just curious if someone is using this, otherwise we have a too
> optimistic documentation here :))
>
> Stipe
>
> [EMAIL PROTECTED]
> ---
> Wapme Systems AG
>
> Münsterstr. 248
> 40470 Düsseldorf
>
> Tel: +49-211-74845-0
> Fax: +49-211-74845-299
>
> E-Mail: [EMAIL PROTECTED]
> Internet: http://www.wapme-systems.de
> ---
> wapme.net - wherever you are
>





Re: anyone using mutli-cast GET requests

2002-01-02 Thread Stipe Tolj

Stefan Cars wrote:
> 
> What do you meanwith multi-cast GET ?

the user guide states at
http://www.kannel.3glab.org/download/kannel-userguide-snapshot/userguide.html#AEN2521

that the "to=" argument may contain multiple receivers, but I can't
see any implementation of this is the code?! 

I'm just curious if someone is using this, otherwise we have a too
optimistic documentation here :))

Stipe

[EMAIL PROTECTED]
---
Wapme Systems AG

Münsterstr. 248
40470 Düsseldorf

Tel: +49-211-74845-0
Fax: +49-211-74845-299

E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are




anyone using mutli-cast GET requests

2002-01-02 Thread Stipe Tolj

for the sendsms HTTP interface?

Any if yes, which smsc? 

I'm currently figuring out in the code where this is supported for the
GET method, but I can't find it. Any I remember that the user's guide
that's that multiple receivers are allowed seperated with a blank in
the "to=" argument.

Stipe

[EMAIL PROTECTED]
---
Wapme Systems AG

Münsterstr. 248
40470 Düsseldorf

Tel: +49-211-74845-0
Fax: +49-211-74845-299

E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
---
wapme.net - wherever you are