Modify

#850 closed defect (fixed)

bitlbee 3.0.3 will not connect to msn

Reported by: msoulier@… Owned by:
Priority: major Milestone:
Component: BitlBee Version: 3.0.3
Keywords: Cc:
IRC client+version: Client-independent Operating System: Linux
OS version/distro: Debian stable

Description

I am using Debian stable. With 1.2.8 I have no problem connecting to MSN, although my current status always shows as available. I tried building 3.0.3 and running that, but it will not connect to MSN. Well, it connects, and then fails to do anything from there.

20:41:17 -!- mode/&bitlbee [-C] by root
20:41:17 <@root> Password accepted, settings and accounts loaded
20:41:17 <@root> Trying to get all accounts connected...
20:41:17 <@root> msn - Logging in: Connecting
20:41:17 <@root> twitter - Logging in: Connecting
20:41:17 -!- twitter_msoulier [twitter_msoulier@twitter] has joined &bitlbee
20:41:17 -!- ServerMode/&bitlbee [+v twitter_msoulier] by bear
20:41:17 <@root> twitter - Logging in: Getting contact list
20:41:17 <@root> msn - Logging in: Connected to server, waiting for reply
20:41:17 <@root> msn - Logging in: Transferring to other server
20:41:17 <@root> msn - Logging in: Connected to server, waiting for reply
20:41:20 <@root> msn - Logging in: Authenticated, getting buddy list
20:41:20 <@root> twitter - Logging in: Getting initial statuses
20:41:20 -!- mode/&bitlbee [+C] by root
20:41:21 <@root> twitter - Logging in: Logged in
20:42:32 <@msoulier> account list
20:42:32 <@root>  0 (msn): msn, msoulier-microsloth@digitaltorque.ca (connecting)
20:42:32 <@root>  1 (twitter): twitter, msoulier (connected)
20:42:32 <@root> End of account list
20:43:17 <@root> msn - Login error: Connection timeout
20:43:17 <@root> msn - Logging in: Signing off..
20:43:17 <@root> msn - Logging in: Reconnecting in 5 seconds..

and so on and so on...

Meanwhile, 1.2.8 from Debian works, and other clients work.

Attachments (0)

Change History (61)

comment:1 Changed at 2011-11-08T02:20:57Z by pezz <bitlbee@…>

Exact same problem here, just started happening today.

Bitlbee 3.0.3 on Arch Linux.

comment:2 Changed at 2011-11-08T08:58:33Z by nullscan

Same for me here, as of today bitlbee 3.0.3 times out after authentication but before (or while) getting buddy list from msn. Debian testing.

comment:3 Changed at 2011-11-08T10:46:37Z by luke@…

Same issue... using 3.0.1-6.fc13

comment:4 Changed at 2011-11-08T10:58:54Z by Wilmer van der Gaast <wilmer@…>

Yes, I can reproduce it too, which will hopefully make fixing it easier.

comment:5 Changed at 2011-11-08T13:49:08Z by anonymous

FreeBSD - BitlBee 3.0.1

Happened today. Impossible to reconnect.

Update to 3.0.3

Same problem.

comment:6 Changed at 2011-11-08T14:08:33Z by gcr@…

Same here, exact same error. Arch Linux, bitlbee 3.0.3-4.

comment:7 Changed at 2011-11-08T14:19:12Z by Wilmer van der Gaast <wilmer@…>

I think it's safe to say this is a common problem so no need for more AOLing guys and gals. :-) I saw MS is returning a HTTP 405 now for whatever reason. If someone already knows more than that, please do share.

comment:8 Changed at 2011-11-08T14:22:36Z by msoulier@…

Please note my original comment in the report that 1.2.8 *does* work. msnlib for Python also works.

comment:9 Changed at 2011-11-08T15:06:40Z by lockyc@…

It was working on the debian package version, but stopped working when i installed 3.0.3

comment:10 Changed at 2011-11-08T16:33:47Z by wchen

Same problem here.
BitlBee 3.0.3
API version 030003
Linux 2.6.32-34-generic-pae #77-Ubuntu SMP Tue Sep 13 21:16:18 UTC 2011 i686 GNU/Linux

Keeps doing this:
08:37 <@root > msn - Logging in: Connecting
08:37 <@root > msn - Logging in: Connected to server, waiting for reply
08:37 <@root > msn - Logging in: Transferring to other server
08:37 <@root > msn - Logging in: Connected to server, waiting for reply
08:37 <@root > msn - Logging in: Authenticated, getting buddy list
08:39 <@root > msn - Login error: Connection timeout
08:39 <@root > msn - Logging in: Signing off..
08:39 <@root > msn - Logging in: Reconnecting in 900 seconds..

comment:11 Changed at 2011-11-08T21:01:50Z by anonymous

This issue is also working with jabber and google chat.

Debian/arm

comment:12 Changed at 2011-11-08T21:45:07Z by anonymous

A temporary workaround is to build with libpurple :

$ ./configure --purple=1

comment:13 Changed at 2011-11-08T23:49:03Z by wilmer

Yup, 1.2.8 with the old MSN module and libpurple will work. 3.0.x currently do not. I'm on a holiday in Hong Kong now and frankly got better things to do than diving into MSN Messenger internals. This is what I know:

This request, which used to work:

POST /abservice/SharingService.asmx HTTP/1.0
Host: contacts.msn.com
Accept: */*
User-Agent: BitlBee bzr-devel-821
Content-Type: text/xml; charset=utf-8
SOAPAction: http://www.msn.com/webservices/AddressBook/FindMembership
Content-Length: 2173
Cache-Control: no-cache

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
    <soap:Header xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
        <ABApplicationHeader xmlns="http://www.msn.com/webservices/AddressBook">
            <ApplicationId xmlns="http://www.msn.com/webservices/AddressBook">CFE80F9D-180F-4399-82AB-413F33A1FA11</ApplicationId>
            <IsMigration xmlns="http://www.msn.com/webservices/AddressBook">false</IsMigration>
            <PartnerScenario xmlns="http://www.msn.com/webservices/AddressBook">Initial</PartnerScenario>
        </ABApplicationHeader>
        <ABAuthHeader xmlns="http://www.msn.com/webservices/AddressBook">
            <ManagedGroupRequest xmlns="http://www.msn.com/webservices/AddressBook">false</ManagedGroupRequest>
    ....removed lots more XML vomit

And also the other SOAP request done at login time, /abservice/abservice.asmx / http://www.msn.com/webservices/AddressBook/ABFindAll , get a HTTP 405 "Method not allowed" response. I can't really find details on what it means and probably it could be anything. Someone (which might be me but only if I'm bored tonight) should see how these requests are done differently by other clients.

comment:14 Changed at 2011-11-09T10:06:54Z by nullscan

Would it be possible that Microsoft allows the POST you do on the SharingService.amsx URI do be done only via https since yesterday? Using pidgin with MSN protocol (not WLM) and forcing HTTP method on the server i get an https conversation after the name resolution of local-bay.contacts.msn.com.nstatic and right after that before anything else an SSLv2 (instead of v3 i noticed in bitlbee but i guess that is OK) certificate exchange. If i find some spare time later i will try to hack around the bitlbee code to switch the conversation to SSL unless you have found something else and i am way off with my assumptions :)

comment:15 Changed at 2011-11-09T16:32:54Z by valiouk@…

The problem is with the request that wilmer has shown. MSN is currently responding with a redirect to local-bay.contacts.msn.com for this request. I have fixed it (quickly and dirty) for myself by changing every occurence of contacts.msn.com with local-bay.contacts.msn.com in protocols/msn/soap.h and recompiling.

comment:16 Changed at 2011-11-09T21:01:59Z by anonymous

Seems that the http_client.c code doesn't handle 301 responses properly. I'm vaguely trying to debug it, but I'm not familiar with that code. Anyone looking into it or shall I proceed further ?

comment:17 Changed at 2011-11-09T21:04:19Z by anonymous

The quick fix works for me too.

comment:18 Changed at 2011-11-10T00:20:07Z by anonymous

patch to bitlbee 3.0.3:

diff -rupN bitlbee-3.0.3.old/protocols/msn/soap.h bitlbee-3.0.3/protocols/msn/soap.h --- bitlbee-3.0.3.old/protocols/msn/soap.h 2011-06-12 08:53:51.000000000 -0300 +++ bitlbee-3.0.3/protocols/msn/soap.h 2011-11-09 21:35:56.000000000 -0200 @@ -115,7 +115,7 @@ int msn_soapq_flush( struct im_connectio

"<wst:RequestType>http://schemas.xmlsoap.org/ws/2004/04/security/trust/Issue</wst:RequestType>" \ "<wsp:AppliesTo>" \

"<wsa:EndpointReference>" \

  • "<wsa:Address>contacts.msn.com</wsa:Address>" \

+ "<wsa:Address>local-bay.contacts.msn.com</wsa:Address>" \

"</wsa:EndpointReference>" \

"</wsp:AppliesTo>" \ "<wsse:PolicyReference xmlns=\"http://schemas.xmlsoap.org/ws/2003/06/secext\" URI=\"MBI\"></wsse:PolicyReference>" \

@@ -198,7 +198,7 @@ int msn_soap_oim_send_queue( struct im_c

"</soap:Body>" \

"</soap:Envelope>"

-#define SOAP_MEMLIST_URL "http://contacts.msn.com/abservice/SharingService.asmx" +#define SOAP_MEMLIST_URL "http://local-bay.contacts.msn.com/abservice/SharingService.asmx"

#define SOAP_MEMLIST_ACTION "http://www.msn.com/webservices/AddressBook/FindMembership"

#define SOAP_MEMLIST_PAYLOAD \

@@ -233,7 +233,7 @@ int msn_soap_memlist_request( struct im_

int msn_soap_memlist_edit( struct im_connection *ic, const char *handle, gboolean add, int list );

-#define SOAP_ADDRESSBOOK_URL "http://contacts.msn.com/abservice/abservice.asmx" +#define SOAP_ADDRESSBOOK_URL "http://local-bay.contacts.msn.com/abservice/abservice.asmx"

#define SOAP_ADDRESSBOOK_ACTION "http://www.msn.com/webservices/AddressBook/ABFindAll"

#define SOAP_ADDRESSBOOK_PAYLOAD \

comment:19 Changed at 2011-11-10T00:21:11Z by necropresto

i forgot the code block.

diff -rupN bitlbee-3.0.3.old/protocols/msn/soap.h bitlbee-3.0.3/protocols/msn/soap.h
--- bitlbee-3.0.3.old/protocols/msn/soap.h      2011-06-12 08:53:51.000000000 -0300
+++ bitlbee-3.0.3/protocols/msn/soap.h  2011-11-09 21:35:56.000000000 -0200
@@ -115,7 +115,7 @@ int msn_soapq_flush( struct im_connectio
                "<wst:RequestType>http://schemas.xmlsoap.org/ws/2004/04/security/trust/Issue</wst:RequestType>" \
                "<wsp:AppliesTo>" \
                    "<wsa:EndpointReference>" \
-                       "<wsa:Address>contacts.msn.com</wsa:Address>" \
+                       "<wsa:Address>local-bay.contacts.msn.com</wsa:Address>" \
                    "</wsa:EndpointReference>" \
                "</wsp:AppliesTo>" \
                "<wsse:PolicyReference xmlns=\"http://schemas.xmlsoap.org/ws/2003/06/secext\" URI=\"MBI\"></wsse:PolicyReference>" \
@@ -198,7 +198,7 @@ int msn_soap_oim_send_queue( struct im_c
   "</soap:Body>" \
 "</soap:Envelope>"
 
-#define SOAP_MEMLIST_URL "http://contacts.msn.com/abservice/SharingService.asmx"
+#define SOAP_MEMLIST_URL "http://local-bay.contacts.msn.com/abservice/SharingService.asmx"
 #define SOAP_MEMLIST_ACTION "http://www.msn.com/webservices/AddressBook/FindMembership"
 
 #define SOAP_MEMLIST_PAYLOAD \
@@ -233,7 +233,7 @@ int msn_soap_memlist_request( struct im_
 int msn_soap_memlist_edit( struct im_connection *ic, const char *handle, gboolean add, int list );
 
 
-#define SOAP_ADDRESSBOOK_URL "http://contacts.msn.com/abservice/abservice.asmx"
+#define SOAP_ADDRESSBOOK_URL "http://local-bay.contacts.msn.com/abservice/abservice.asmx"
 #define SOAP_ADDRESSBOOK_ACTION "http://www.msn.com/webservices/AddressBook/ABFindAll"
 
 #define SOAP_ADDRESSBOOK_PAYLOAD \

comment:20 Changed at 2011-11-10T01:46:11Z by pezz

Patch works for me, Arch Linux, bitlbee 3.0.3.

comment:21 Changed at 2011-11-10T03:39:43Z by wilmer

changeset:devel,823 Many thanks!

No clue if this is going to work forever but it's good to at least have a workaround. I'll try to get this rolled out to testing and im at least.

comment:22 Changed at 2011-11-10T07:44:35Z by Huittinen Massive

For me it is http://local-sn.contacts.msn.com/abservice/SharingService.asmx dunno if this has changed in last 4 hours, but local-bay certainly does not work for me.

comment:23 Changed at 2011-11-10T08:56:19Z by Huittinen Massive

Plausibly 'bay' is MS DC in bay area and 'SN' maybe in San Antonio. And depending on your source IP, you're redirected to one of them (or maybe even more options). So probably we should continue to use contacts.msn.com and just follow redirects.

comment:24 Changed at 2011-11-10T09:22:59Z by anonymous

Following the redirects is offcourse the correct implementation. But just to add a data point: from Europe (Belgium) it's also redirecting to local-bay.contacts.msn.com.

comment:25 Changed at 2011-11-10T15:32:07Z by wilmer

So Mr. anonymous, did you actually see 301s coming in? Because I didn't while debugging this. http_client does support redirects although the code for it *is* a bit crappy..

There's also some SOAP-specific redirect mechanism which may be used here. I do (or used to) have support for it in the Passport auth. code, should be easy to extend that. But I simply haven't seen any redirect..

comment:26 Changed at 2011-11-10T16:39:54Z by Ced

Freebsd 8.2 amd64, Bitlbee 3.0.3

I have applied the patch above and it doesn't seem to have fixed the issue on my side.

i still get

root: msn - Logging in: Connecting
root: msn - Logging in: Connected to server, waiting for reply
root: msn - Logging in: Transferring to other server
root: msn - Logging in: Connected to server, waiting for reply
root: msn - Logging in: Authenticated, getting buddy list
root: msn - Login error: Connection timeout
root: msn - Logging in: Signing off..

I tried with local-bay and local-sn, no difference. Not sure if it's revelant but im from Belgium.

comment:27 Changed at 2011-11-10T17:01:22Z by PowerKe

(I posted comment 24) I did see 301's coming in for local-bay.contacts.msn.com and have recompiled my client with that hostname. Unfortunately, my C++ isn't very good to follow the code easily and I also have no IDE installed for C++. It seems that the redirects get re-queried but with a GET request instead of a POST request and a wrong 'Host:' header. I'm also mailing you a tcpdump of the 'getting buddy list'.

comment:28 Changed at 2011-11-10T17:29:13Z by valiouk@…

my 2 cents

POST /abservice/SharingService.asmx HTTP/1.0
Host: contacts.msn.com
Accept: */*
User-Agent: BitlBee 3.0.3-1
Content-Type: text/xml; charset=utf-8
SOAPAction: "http://www.msn.com/webservices/AddressBook/FindMembership"
Content-Length: 2193
Cache-Control: no-cache

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><ABApplicationHeader xmlns="http://www.msn.com/webservices/AddressBook"><ApplicationId xmlns="http://www.msn.com/webservices/AddressBook">CFE80F9D-180F-4399-82AB-413F33A1FA11</ApplicationId><IsMigration xmlns="http://www.msn.com/webservices/AddressBook">false</IsMigration><PartnerScenario xmlns="http://www.msn.com/webservices/AddressBook">Initial</PartnerScenario></ABApplicationHeader><ABAuthHeader xmlns="http://www.msn.com/webservices/AddressBook"><ManagedGroupRequest xmlns="http://www.msn.com/webservices/AddressBook">false</ManagedGroupRequest>
... lots more XML vomit :)

HTTP/1.1 301 Moved Permanently
Cache-Control: private, max-age=0
Keep-Alive: true
Content-Length: 832
Content-Type: text/xml; charset=utf-8
Location: http://local-bay.contacts.msn.com/abservice/SharingService.asmx
X-MSNSERVER: BAYCDP9011139
X-AspNet-Version: 4.0.30319
Date: Wed, 09 Nov 2011 16:17:15 GMT
Connection: close

<?xml version="1.0" encoding="utf-8"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><soap:Header><ServiceHeader xmlns="http://www.msn.com/webservices/AddressBook"><Version>16.02.2225.0001</Version><CacheKey>14r2;dfJeZE6jK/esId6mQ1MTXiR2J8kyQP0lmy1KTYcXt+Kegbp054gCbDuO/4xDEBNOCc+LC2hvsOez6PwYToWcdf8QU69WgJ9e83Ye2y8BeEW9qFn6HE2V6gQTiga9XdndBj0ulGw/w3tJL1ppMDNSQxWZFQLxo2N+oVfA7vPivq4=</CacheKey><CacheKeyChanged>true</CacheKeyChanged><PreferredHostName>proxy-bay.contacts.msn.com</PreferredHostName><SessionId>ABCH.e2788cd7-18f5-4b13-8b16-c1e211b99be5</SessionId></ServiceHeader></soap:Header><soap:Body><FindMembershipResponse xmlns="http://www.msn.com/webservices/AddressBook" /></soap:Body></soap:Envelope>

comment:29 Changed at 2011-11-10T23:13:55Z by Wilmer van der Gaast <wilmer@…>

Ahh!

I think I get it now. What's happening most likely is that I'm getting a 405 to whatever BitlBee already redirected to. http_client does redirects and the soap module wouldn't even be aware of that fact.

And then probably it's doing some GET/POST mixup..

comment:30 Changed at 2011-11-10T23:44:06Z by wilmer

Yep, it's switching from post to GET which should not be done for 301s. Okay, we have a root cause, thanks for your 2 cents. :-)

comment:31 Changed at 2011-11-10T23:56:35Z by wilmer

changeset:devel,156

I already thought I did this differently before. Looks like POST redirection was buggy though, leaving out POST data..

comment:32 Changed at 2011-11-11T03:16:25Z by IvánJr

The patch given by Señor Necropresto works for me: 3.0.3 on Debian 6.0.3 (i386).

Saludos!

comment:33 Changed at 2011-11-11T07:25:08Z by anonymous

msn works fine with bitlbee 3.0.3-5 on Arch Linux

comment:34 Changed at 2011-11-11T19:20:13Z by anonymous

Updated to bzr-823 but still doesn't work unless I configure it with --purple=1.

comment:35 Changed at 2011-11-11T21:17:25Z by Nuno J. Silva <nunojsilva@…>

Anonymous (c34), wilmer appears to have found the issue (HTTP 301 on GET, POST, BREW, or other request is always followed by GET, while -- I guess -- it should be followed by the same kind of request), but he made no change yet in the codebase to fix the redirect issue (probably because he wants to be sure fixing it does not break anything else).

He added a partial workaround that will fix it for the people who get redirected to local-bay.contacts.msn.com, which is included in revision 823 -- so I guess you're being redirected to another server.

I guess you *can* use the patch, you just need to find out which server are you being redirected to and hardcode its address the same way [1] does.

[1] http://bugs.bitlbee.org/bitlbee/changeset/devel%2C823

comment:36 Changed at 2011-11-11T23:40:51Z by anonymous

MSN drop-kicked me off last night around midnight, and it has been trying to reconnect all day long (every 900 seconds). It says it authenticated, getting buddy list... then login error: connection timeout. Is this problem related?

comment:37 Changed at 2011-11-11T23:43:17Z by bwelmers

I did the s/contacts.msn.com/local-bay.contacts.msn.com/g thing on soap.h. It works for some MSN accounts but not for all (despite using one outgoing IP address of the server). It the problem indeed resists in the http_client.c functionality, it should be fixed there.

comment:38 Changed at 2011-11-11T23:56:18Z by Nuno J. Silva <nunojsilva@…>

Anonymous (c36), it is. If you see the log in the report, above, these are the MSN-related messages there. Microsoft changed something on their side and now the buddy list request (a SOAP request) times out.

bwelmers: I did not try it myself (yet?), but keep in mind it's more of a *workaround*. I don't know what's the best way to find the right server address, I guess there's some debugging feature (which was changed in revision 822 to print the headers from SOAP requests), but I'd advise finding out what's the right address for failing accounts.

You can also try reverting the change that enforces GET requests, but I guess there must be some reason why that has not been undone (yet?).

comment:39 Changed at 2011-11-12T00:28:08Z by Ced

Freebsd 8.2 amd64, Bitlbee 3.0.3

I finaly got it working on my end without the libpurple option. This is what i used.

<wsa:Address>omega.contacts.msn.com</wsa:Address>
#define SOAP_MEMLIST_URL "http://local-sn.contacts.msn.com/abservice/SharingService.asmx"
#define SOAP_ADDRESSBOOK_URL "http://local-sn.contacts.msn.com/abservice/abservice.asmx"

comment:40 Changed at 2011-11-12T11:57:26Z by anonymous

Same problem here. I have 3 MSN accounts and all of them got disconnected in the past couple of days.

After reading this thread I decided to test the soap.h changes and here is what I noticed:

When changing the 3 contacts.msn.com entries to local-bay.contacts.msn.com I managed to get 1 of my 3 accounts connected. Looking in wireshark logs I noticed some redirect entries to local-sn.contacts.msn.com. So I tried these entries in the soap.h file and now the 2 other accounts got connected. So from what I can see the server to be used depends on the account. Changing the soap.h file will thus not resolve the issue for everyone.

So from my experience I would guess the best way forward is to make the "static" entries in the soap.h entry variable based on the redirect requests send out by the MSN server. However since I'm no developper I'm not sure if this is something that can be easily implemented.

I hope this helps to resolve the issue as I like bitlbee alot ;-)

comment:41 Changed at 2011-11-12T13:17:25Z by Wilmer van der Gaast <wilmer@…>

Thanks for all your thinking guys. :-) Yes, I already figured the redirection target depends on the account, not on your physical location. It makes sense, apparently your account data is just stored in a specific datacenter instead of magically replicated everywhere. So on the first connection attempt you get forwarded to whatever datacenter has your actual data.

The fix will be to make lib/http_client.c do redirects on POSTs properly. I'm not sure if I'll have time to do this too soon..

comment:42 Changed at 2011-11-12T13:53:19Z by anonymous

i think that bitlbee should have a config file to change the urls to the msn servers. in this way, a recompiling will be unnecesary. what do you think about that?

comment:43 Changed at 2011-11-12T14:20:27Z by Wilmer van der Gaast <wilmer@…>

I'm not going to spend time on temporary solutions either. If anyone else is interested in doing that, feel free.

comment:44 Changed at 2011-11-12T16:44:26Z by bwelmers

The next patch on http_client.c will fix the POST thing and replaces the Host: header in the new request. Without replacing the Host header the MSN servers won't respond properly either. I'm not really familiar with C so the string manipulation won't be the most beautiful one you have ever seen.

--- Downloads/bitlbee-3.0.3/lib/http_client.c	2011-06-12 13:53:51.000000000 +0200
+++ PRJ/bitlbee/bitlbee-3.0.3/lib/http_client.c	2011-11-12 17:35:44.000000000 +0100
@@ -353,6 +353,7 @@ got_reply:
 			/* A whole URL */
 			url_t *url;
 			char *s;
+			char *s2;
 			
 			s = strstr( loc, "\r\n" );
 			if( s == NULL )
@@ -369,12 +370,15 @@ got_reply:
 			}
 			
 			/* Okay, this isn't fun! We have to rebuild the request... :-( */
-			new_request = g_malloc( req->request_length + strlen( url->file ) );
+			new_request = g_malloc( req->request_length + strlen( url->file ) + strlen(url->host) );
 			
 			/* So, now I just allocated enough memory, so I'm
 			   going to use strcat(), whether you like it or not. :-) */
 			
-			sprintf( new_request, "GET %s HTTP/1.0", url->file );
+			if (strstr(req->request, "POST") == req->request)
+				sprintf( new_request, "POST %s HTTP/1.0", url->file );
+			else
+				sprintf( new_request, "GET %s HTTP/1.0", url->file );
 			
 			s = strstr( req->request, "\r\n" );
 			if( s == NULL )
@@ -384,9 +388,19 @@ got_reply:
 				g_free( url );
 				goto cleanup;
 			}
+			new_host = g_strdup( url->host );
 			
+			/* Replace Host: header */
+			s2 = strstr(s, "\r\nHost:");
+			s2 = s2 + 2;
+			*s2 = 0; // terminate string s temporary
 			strcat( new_request, s );
-			new_host = g_strdup( url->host );
+			strcat( new_request, "Host: ");
+			strcat( new_request, new_host);
+			*s2 = 'H'; // restore string
+			s = strstr(s2, "\r\n"); // next header
+			strcat( new_request, s );
+			
 			new_port = url->port;
 			new_proto = url->proto;
 			

comment:45 in reply to:  description Changed at 2011-11-12T19:51:10Z by Richard Burnison

I've included a working patch below; however, it may need some vetting.

It allows Bitlbee to follow HTTP redirects using the original HTTP method, which, as I understand, is a bit closer to the behaviour defined for 301 and 302 HTTP response codes in the RFC specifications.

Further, the patch allows the ability to follow absolute redirections.

=== modified file 'lib/http_client.c'
--- lib/http_client.c   2011-04-18 14:14:28 +0000
+++ lib/http_client.c   2011-11-12 19:34:16 +0000
@@ -368,14 +368,25 @@
                                goto cleanup;
                        }
                        
-                       /* Okay, this isn't fun! We have to rebuild the request... :-( */
-                       new_request = g_malloc( req->request_length + strlen( url->file ) );
+                       /* Okay, this isn't fun! We have to rebuild the request... :-(
+                          The new request will have the same amount of memory as the original,
+                          allowing for a safe reuse of the original HTTP method. Further,
+                          the addition of a new host may change the overall size. */
+                       new_request = g_malloc( req->request_length + strlen( url->file ) + strlen(url->host));
                        
+                       int method_len = strcspn(req->request, " ");
+                       char *method = g_malloc(sizeof(char) * method_len + 1);
+                       strncpy(method, req->request, method_len);
+                       strcpy(method + method_len, "\0");
+
                        /* So, now I just allocated enough memory, so I'm
                           going to use strcat(), whether you like it or not. :-) */
                        
-                       sprintf( new_request, "GET %s HTTP/1.0", url->file );
+                       sprintf( new_request, "%s %s HTTP/1.0", method, url->file );
                        
+                       g_free(method);
+
+                       /* Strip off the first original line. */
                        s = strstr( req->request, "\r\n" );
                        if( s == NULL )
                        {
@@ -385,7 +396,18 @@
                                goto cleanup;
                        }
                        
-                       strcat( new_request, s );
+                       /* Add everything up to Host header. */
+                       char* host_starts = strstr(s, "Host: ");
+                       strncat(new_request, s, strlen(s) - strlen(host_starts));
+
+                       /* Add new Host header. */
+                       strcat(new_request, "Host: ");
+                       strncat(new_request, url->host, strlen(url->host));
+
+                       /* Add everything after original Host header. */
+                       char* host_ends = strstr(host_starts, "\r\n");
+                       strcat(new_request, host_ends);
+
                        new_host = g_strdup( url->host );
                        new_port = url->port;
                        new_proto = url->proto;

comment:46 Changed at 2011-11-12T19:57:20Z by Nuno J. Silva <nunojsilva@…>

wilmer already fixed it in the source some hours ago, see changeset:devel,824

The fix works here.

comment:47 Changed at 2011-11-13T02:50:48Z by wilmer

Resolution: fixed
Status: newclosed

Err. changeset:devel,824 . Maybe I really should've posted a comment here. :-P

Anyway, together with changeset:devel,825 this is now fixed for real. The code's getting messy but it will do for now.

Releasing 3.0.4 would be nice, but I need to fix #838 first. :-/

comment:48 Changed at 2011-11-13T14:16:17Z by Jess

How do we update the 3.0.3 code to use this new fix? I'm pretty new at bug reporting and patching ;)

comment:49 in reply to:  48 ; Changed at 2011-11-13T15:12:40Z by wilmer

Replying to Jess:

How do we update the 3.0.3 code to use this new fix? I'm pretty new at bug reporting and patching ;)

Hopefully you run Debian or Ubuntu or so, in which case the answer is very simple:

http://wiki.bitlbee.org/Packages

comment:50 Changed at 2011-11-13T15:34:58Z by Jess

Thanks for the reply wilmer, but I use a compiled version (got a shell on a gentoo box) so I have to compile manually.

Is this patch now incloded in the 3.0.3 release or do I have to fiddle with SVN?

Jess x

comment:51 Changed at 2011-11-13T15:37:57Z by Wilmer van der Gaast <wilmer@…>

"bzr branch http://code.bitlbee.org/bitlbee/" should download it. But if you don't have bzr available or if you have problems rebuilding the documentation, you can download tarballs from http://code.bitlbee.org/tarballs/?C=M;O=D

comment:52 in reply to:  49 ; Changed at 2011-11-14T22:17:55Z by anonymous

Replying to wilmer:

Releasing 3.0.4 would be nice, but I need to fix #838 first. :-/

If that takes too long, could you upload a version with this fix to the debian repositories in the mean time?

Thanks in advance

comment:53 in reply to:  52 Changed at 2011-11-14T22:51:19Z by anonymous

Replying to anonymous:

Replying to wilmer:

Releasing 3.0.4 would be nice, but I need to fix #838 first. :-/

If that takes too long, could you upload a version with this fix to the debian repositories in the mean time?

Thanks in advance

I'd love this as well. I've stopped using bitlbee for the last few days because of this bug.

comment:54 Changed at 2011-11-15T00:05:43Z by Wilmer van der Gaast <wilmer@…>

The whole reason I'm not doing a release is because I do not have time.

Debian users can just use snapshots from http://code.bitlbee.org/debian/ so there's certainly no reason to spend time on that.

comment:55 Changed at 2011-11-15T10:07:00Z by anonymous

Are there any nightly equiv for RPMs?

comment:56 Changed at 2011-11-15T10:13:05Z by Wilmer van der Gaast <wilmer@…>

Nope.. If someone can give me scripts to build them in a chroot or so I could try that though.

comment:57 Changed at 2011-11-15T10:19:39Z by pezz

I don't get why a 3.0.4 version based on this fix can't be released due to bug #838 -- a weird Twitter time bug -- not being fixed?

Releasing a 3.0.4 with this official fix (which basically makes an entire protocol work properly - MSN) will help rolling release distros like Arch and others that want a stable release to base on.

comment:58 in reply to:  50 ; Changed at 2011-11-16T01:35:37Z by Xelnor

Replying to Jess:

Thanks for the reply wilmer, but I use a compiled version (got a shell on a gentoo box) so I have to compile manually.

Is this patch now incloded in the 3.0.3 release or do I have to fiddle with SVN?

Jess x

Hi Jess,

For gentoo, the 3.0.3-r1 version (added to portage on monday) contains this exact patch, which fixes the issue :)

-- Xelnor

comment:59 in reply to:  57 Changed at 2011-11-16T15:32:22Z by wilmer

@pezz: It's not a time bug, it's a bug where it stops fetching updates entirely.

Distro packagers can release a 3.0.3-2 or something with this fix.

What I don't get is how many more times I have to explain people that I do not have time right now.

comment:60 Changed at 2011-11-17T23:04:48Z by luke@…

Should be able to get the RPM for FC[15/16/17] at http://koji.fedoraproject.org/koji/buildinfo?buildID=273776

Am running bitlbee-3.0.3-6.fc15.i686.rpm and msn works again.

comment:61 in reply to:  58 Changed at 2011-11-22T09:01:44Z by Jess

Replying to Xelnor:

Replying to Jess:

Thanks for the reply wilmer, but I use a compiled version (got a shell on a gentoo box) so I have to compile manually.

Is this patch now incloded in the 3.0.3 release or do I have to fiddle with SVN?

Jess x

Hi Jess,

For gentoo, the 3.0.3-r1 version (added to portage on monday) contains this exact patch, which fixes the issue :)

-- Xelnor

I don't have access to portage :(

The latest rzr thingy has fixed it for me. Thanks peeps :) Jess

Modify Ticket

Action
as closed The ticket will remain with no owner.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.