function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
FenderchampFenderchamp 

HTTP Response with two "Transfer-Encoding: chunked" headers returned from test.

Hi,  When we are attempting to get a new access_token using a refresh_token on test.salesforce.com 

 

https://test.salesforce.com/services/oauth2/token?grant_type=refresh_token&client_id=3....JFK&refresh_token=5....X==

 

salesforce is returning a return code of 200, but there are 2 Transfer-Encoding Fields with the value of 'chunked' in the response Header

 

This seems to be out of compliance with http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.6

 

Which states

 

Whenever a transfer-coding is applied to a message-body, the set of transfer-codings MUST include "chunked", unless the message is terminated by closing the connection. When the "chunked" transfer- coding is used, it MUST be the last transfer-coding applied to the message-body. The "chunked" transfer-coding MUST NOT be applied more than once to a message-body. These rules allow the recipient to determine the transfer-length of the message

 

 

This behavior is not occuring on our login.salesforce.com instance, and I just noticed that it started happening on Tuesday when my Web client started to reject the double chunked response headers.

 

 

RadnipRadnip

I'd raise a case for this.
jhannahjhannah
Dataville wrote:

I'd raise a case for this.

Case Number 07622995 opened (help.salesforce.com).
ck2ck2

This just started happening to us over the weekend (sometime after mid-day PT Friday Jun 1)

This is a serious problem for us.

 

First, we are seeing it on login.salesforce.com: this is happening on the production org.

 

Part of client infrastructure is Python-based. Python's httplib class concatenates Transfer-Encoding values (as allowed per spec) and when it fails to see "chunked" (instead seeing, "chunked, chunked"), and also fails to see a Content-Length (obviously not there since the server is using chunked TE), it tries to read until close and hangs.

 

I'm new to this forum: where can I check on the status of case 07622995 and potentially elevate its urgency?

 

Thanks,

-CK
SuperfellSuperfell

Do you have a simple repro case for this? I've been unable to reproduce this so far using curl, which shows only a single transfer-encoding:chunked header in the response
ck2ck2

Curl confused me, too - because it doesn't print the duplicated header unless you give the '--trace out.trace' option. When I do that, I can clearly see the duplicated header:

 

<= Recv header, 17 bytes (0x11)
0000: 48 54 54 50 2f 31 2e 31 20 32 30 30 20 4f 4b 0d HTTP/1.1 200 OK.
0010: 0a                                              .
<= Recv header, 10 bytes (0xa)
0000: 53 65 72 76 65 72 3a 20 0d 0a                   Server: ..
<= Recv header, 25 bytes (0x19)
0000: 43 61 63 68 65 2d 43 6f 6e 74 72 6f 6c 3a 20 6e Cache-Control: n
0010: 6f 2d 73 74 6f 72 65 0d 0a                      o-store..
<= Recv header, 28 bytes (0x1c)
0000: 54 72 61 6e 73 66 65 72 2d 45 6e 63 6f 64 69 6e Transfer-Encodin
0010: 67 3a 20 63 68 75 6e 6b 65 64 0d 0a             g: chunked..
<= Recv header, 47 bytes (0x2f)
0000: 43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 61 70 Content-Type: ap
0010: 70 6c 69 63 61 74 69 6f 6e 2f 6a 73 6f 6e 3b 20 plication/json; 
0020: 63 68 61 72 73 65 74 3d 55 54 46 2d 38 0d 0a    charset=UTF-8..
<= Recv header, 28 bytes (0x1c)
0000: 54 72 61 6e 73 66 65 72 2d 45 6e 63 6f 64 69 6e Transfer-Encodin
0010: 67 3a 20 63 68 75 6e 6b 65 64 0d 0a             g: chunked..
<= Recv header, 37 bytes (0x25)
0000: 44 61 74 65 3a 20 54 75 65 2c 20 30 35 20 4a 75 Date: Tue, 05 Ju
0010: 6e 20 32 30 31 32 20 30 34 3a 33 37 3a 33 33 20 n 2012 04:37:33 
0020: 47 4d 54 0d 0a                                  GMT..
<= Recv header, 2 bytes (0x2)
0000: 0d 0a                                           ..
<= Recv data, 345 bytes (0x159)
An even more compelling case is Python code that shows two main web libraries for Python (httplib and urllib2) both failing in different ways: httplib hangs, urllib2 doesn't hang, but doesn't unchunk the data, so JSON parsing fails, etc.

 

data = { "grant_type"    : "refresh_token",
         "client_id"     : CLIENT_ID,
         "client_secret" : CLIENT_SECRET,
         "refresh_token" : REFRESH_TOKEN }
import urllib
encodedData = urllib.urlencode(data)

method = "httplib"
if method == "urllib2":
    try:
        import urllib2
        request = urllib2.Request("https://" + SF_LOGIN_HOST + SF_REFRESH_PATH)
        resultText = urllib2.urlopen(request, encodedData).read()
    except urllib2.HTTPError, httpError:
        logging.info("%s %s" % (httpError.code, httpError.msg))
        exit(1)
else:
    import httplib
    conn = httplib.HTTPSConnection(SF_LOGIN_HOST)
    headers = {"Content-type": "application/x-www-form-urlencoded"}
    conn.request("POST", SF_REFRESH_PATH, encodedData, headers)
    response = conn.getresponse()
    resultText = response.read()
Thanks for any tips/suggestions.
SuperfellSuperfell

Yes, i was using --trace, but was still only getting a single header, i'll try again.

 

But, looks like the auth team knows what the issue is and is working on getting a fix out. I'll update this with more info when i get it.
SuperfellSuperfell

ok, i finally stopped fat fingering the curl options, and can see the same trace as you. 
ck2ck2

Good to hear it's reproducible by others. 

 

Is that case only visible to Salesforce staff? From my partner portal account, I see I can log a new case but not sure how to check status of an existing one. Should I be filing a separate issue?

 

For any others having the same problem, an ugly brute-force hack to Python httplib.py to be tolerant of the bad extra header is to look for these lines of code:

 

        # are we using the chunked-style of transfer encoding?
        tr_enc = self.msg.getheader('transfer-encoding')
        if tr_enc and tr_enc.lower() == "chunked":
and replace with:

 

        # are we using the chunked-style of transfer encoding?
        tr_enc = self.msg.getheader('transfer-encoding')
        if tr_enc and tr_enc.lower()[:7] == "chunked":
SuperfellSuperfell

Not sure why you'd want to log another case, do you have more than one issue (i only see one mentioned in this thread), I updated your case to link it with the bug #, you should be able to call support and get more details on when the fix is being released.
jhannahjhannah
SimonF wrote:

Not sure why you'd want to log another case, do you have more than one issue (i only see one mentioned in this thread), I updated your case to link it with the bug #, you should be able to call support and get more details on when the fix is being released.

What bug # is that? URL? So far all I have on my case (07622995) is "its a know issue and our senior team is working".  Thanks!
jhannahjhannah
ck2 wrote:

For any others having the same problem, an ugly brute-force hack to Python httplib.py to be tolerant of the bad extra header is to look for these lines of code:

For any Perl folk out there, here's our patch to Net::HTTP which survives the bad Salesforce header. (RT#77240) 
SuperfellSuperfell

Its on the issues list now, see http://success.salesforce.com/issues_view?id=a1p30000000S7JNAA0
ck2ck2

Thanks, Simon! That page lists the Fix Status as "Next Patch Release" - does that include an estimated ship date somewhere? (Sorry for all the newbie questions; trying to determine if this is something we should just be patient with for a few days or if we need to roll out patched Python distributions everywhere, etc.)

Thanks, -CK

 
SuperfellSuperfell

You can call support (sorry, yes, you actually have to call) and the support rep should be able to give an estimated release date.
SuperfellSuperfell

Looks like they've started deploying the patch that contains this fix.
jhannahjhannah

test.salesforce.com (cs7.salesforce.com) and login.salesforce.com (prg.my.salesforce.com) look fixed to me. I don't know how to test the others. I get INVALID_SESSION_ID errors when I ignore the returned instance_url and hit the others instances.