Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Still getting "Host returned error code 400" in acra 4.8.2 #376

Closed
andreag85 opened this issue Feb 19, 2016 · 17 comments
Closed

Still getting "Host returned error code 400" in acra 4.8.2 #376

andreag85 opened this issue Feb 19, 2016 · 17 comments

Comments

@andreag85
Copy link

Hi. I'm on Nexus 4 running Android 5.1.1 and acra 4.8.2 in my project, having this error

02-19 15:03:01.576 21022-21040/? W/ACRA: Could not send ACRA Post responseCode=400 message=Bad Request
02-19 15:03:01.578 21022-21040/? E/ACRA: Failed to send crash report for /data/data/xxx/app_ACRA-approved/2016-02-18T13:11:26.073+01:00.stacktrace
                                         org.acra.sender.ReportSenderException: Error while sending JSON report via Http POST
                                             at org.acra.sender.HttpSender.send(HttpSender.java:236)
                                             at org.acra.sender.ReportDistributor.sendCrashReport(ReportDistributor.java:102)
                                             at org.acra.sender.ReportDistributor.distribute(ReportDistributor.java:70)
                                             at org.acra.sender.SenderService.onHandleIntent(SenderService.java:69)
                                             at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:65)
                                             at android.os.Handler.dispatchMessage(Handler.java:102)
                                             at android.os.Looper.loop(Looper.java:135)
                                             at android.os.HandlerThread.run(HandlerThread.java:61)
                                          Caused by: java.io.IOException: Host returned error code 400
                                             at org.acra.util.HttpRequest.send(HttpRequest.java:153)
                                             at org.acra.sender.HttpSender.send(HttpSender.java:233)
                                             at org.acra.sender.ReportDistributor.sendCrashReport(ReportDistributor.java:102) 
                                             at org.acra.sender.ReportDistributor.distribute(ReportDistributor.java:70) 
                                             at org.acra.sender.SenderService.onHandleIntent(SenderService.java:69) 
                                             at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:65) 
                                             at android.os.Handler.dispatchMessage(Handler.java:102) 
                                             at android.os.Looper.loop(Looper.java:135) 
                                             at android.os.HandlerThread.run(HandlerThread.java:61)

My configuration is

@ReportsCrashes(
        formUri = "https://xxx.cloudant.com/acra-co/_design/acra-storage/_update/report",
        mode = ReportingInteractionMode.TOAST,
        resToastText = R.string.crash_toast_text, // optional, displayed as soon as the crash occurs, before collecting data which can take a few seconds
        resDialogText = R.string.crash_dialog_text,
        resDialogCommentPrompt = R.string.crash_dialog_comment_prompt, // optional. When defined, adds a user text field input with this text resource as a label
        resDialogOkToast = R.string.crash_dialog_ok_toast, // optional. displays a Toast message when the user accepts to send a report.
        httpMethod = HttpSender.Method.POST,
        formUriBasicAuthLogin = "xxx",
        formUriBasicAuthPassword = "xxx",
        reportType = HttpSender.Type.JSON)
@william-ferguson-au
Copy link
Member

Has this ever worked before?
What do any logs on the server say?
What server back end are you using?
Are there any other ACRA logs?

@andreag85
Copy link
Author

Yes I just upgraded from 4.6 to 4.8.2 and previous version worked fine
The server is on cloudant so I can't access logs.
And no, those are the only ACRA logs I got

@william-ferguson-au
Copy link
Member

There must be some way to see incoming requests on cloudant. If not, then perhaps cloudant is not an ideal solution.

If all you have to go on is a Http#400 then it will be slow going.

You need to know why the server won't accept the request.

My suggestions

  1. Find a way to get some log out of cloudant for the request to find out why it is being rejected.
  2. Or use Wireshark to capture the 4.8.2 request and a 4.6 request and compare them.

@raviteja06
Copy link

+1 Using Cloudant as server

@william-ferguson-au
Copy link
Member

So @raviteja06 are you getting Http#400 on your CloudAnt server?

@raviteja06
Copy link

I am not able to access any error logs from cloudant server. But previous version was working fine.

@william-ferguson-au
Copy link
Member

So use wireshark to find the differences that are causing you the problem.
If you can't debug your server, I certainly can't.

@raviteja06
Copy link

@william-ferguson-au I am looking at Wireshark data. Can you help me to look for a specific thing?

Below Line highlighted with red

192.168.137.200 184.173.163.133 TCP 54  48827 → 443 [RST] Seq=1 Win=0 Len=0

Frame 24226: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface 0
    Interface id: 0 (\Device\NPF_{7BC03C37-42FD-457A-A3BF-64F98375D368})
    Encapsulation type: Ethernet (1)
    Arrival Time: Feb 23, 2016 11:48:21.731828000 India Standard Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 1456208301.731828000 seconds
    [Time delta from previous captured frame: 0.001486000 seconds]
    [Time delta from previous displayed frame: 0.254636000 seconds]
    [Time since reference or first frame: 1423.301134000 seconds]
    Frame Number: 24226
    Frame Length: 54 bytes (432 bits)
    Capture Length: 54 bytes (432 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ip:tcp]
    [Coloring Rule Name: TCP RST]
    [Coloring Rule String: tcp.flags.reset eq 1]
Ethernet II, Src: HuaweiTe_63:c7:25 (24:df:6a:63:c7:25), Dst: 36:e6:ad:88:d1:ff (36:e6:ad:88:d1:ff)
    Destination: 36:e6:ad:88:d1:ff (36:e6:ad:88:d1:ff)
        Address: 36:e6:ad:88:d1:ff (36:e6:ad:88:d1:ff)
        .... ..1. .... .... .... .... = LG bit: Locally administered address (this is NOT the factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: HuaweiTe_63:c7:25 (24:df:6a:63:c7:25)
        Address: HuaweiTe_63:c7:25 (24:df:6a:63:c7:25)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.137.200, Dst: 184.173.163.133
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes
    Differentiated Services Field: 0x20 (DSCP: CS1, ECN: Not-ECT)
    Total Length: 40
    Identification: 0xf0f9 (61689)
    Flags: 0x02 (Don't Fragment)
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: TCP (6)
    Header checksum: 0xa312 [validation disabled]
    Source: 192.168.137.200
    Destination: 184.173.163.133
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
Transmission Control Protocol, Src Port: 48827 (48827), Dst Port: 443 (443), Seq: 1, Len: 0
    Source Port: 48827
    Destination Port: 443
    [Stream index: 148]
    [TCP Segment Len: 0]
    Sequence number: 1    (relative sequence number)
    Acknowledgment number: 0
    Header Length: 20 bytes
    Flags: 0x004 (RST)
        000. .... .... = Reserved: Not set
        ...0 .... .... = Nonce: Not set
        .... 0... .... = Congestion Window Reduced (CWR): Not set
        .... .0.. .... = ECN-Echo: Not set
        .... ..0. .... = Urgent: Not set
        .... ...0 .... = Acknowledgment: Not set
        .... .... 0... = Push: Not set
        .... .... .1.. = Reset: Set
        .... .... ..0. = Syn: Not set
        .... .... ...0 = Fin: Not set
        [TCP Flags: *********R**]
    Window size value: 0
    [Calculated window size: 0]
    [Window size scaling factor: 256]
    Checksum: 0xfa34 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
    Urgent pointer: 0

@william-ferguson-au
Copy link
Member

Are you sure this is even the message?
On the surface it doesn't look like it.

Where is the HTTP section?

You want to compare the HTTP section of the request with the HTTP section of the request made using ACRA-4.6.0 (or whatever version that works for you).

@F43nd1r
Copy link
Member

F43nd1r commented Feb 25, 2016

Sidenote: 4.8.2 is NOT generally broken. I can send reports to Acralyzer (hosted at Smileupps)

@william-ferguson-au
Copy link
Member

@F43nd1r good clarification. Yes and I am sending reports to Splunk/BugSense.

@raviteja06
Copy link

Can someone help (with documentation) on how to set ACRA/Acralyzer on Smileupps/Splunk/Bugsense etc. ?
Thanks in advance.

@william-ferguson-au
Copy link
Member

This is the config that I am using on Splunk/BugSense.

Back in 2010, BugSense changed policy and started killing POSTs that were too big. Returning 400.
But it was clear in the response as to why the POST had been killed.

So you can try being selective about the fields you report.

@ReportsCrashes(
        formUri = "http://www.bugsense.com/api/acra?api_key= MY_ACRA_KEY",
        mode = ReportingInteractionMode.TOAST,
        resToastText = R.string.crash_toast_text,
        socketTimeout = 20000, // This is the milliseconds waiting for data.
        customReportContent = { 
                   // These are the field used by Bugsense. 
                   //  I needed to trim down because the Post was too big and Bugsense was canning it with a Http-400 (in 2010)
                ReportField.DISPLAY,
                ReportField.SETTINGS_SECURE,
                ReportField.STACK_TRACE,
                ReportField.CUSTOM_DATA,
                ReportField.USER_CRASH_DATE,
                ReportField.PHONE_MODEL,
                ReportField.APP_VERSION_NAME,
                ReportField.APP_VERSION_CODE,
                ReportField.PACKAGE_NAME,
                ReportField.ANDROID_VERSION
        }
)

@raviteja06
Copy link

I figured out the issue. Cloudant is not accepting calls if the user sends API key and password as basic authentication. I create a dummy user in cloudant and added to my main account with write access and use that as shown below:
formUriBasicAuthLogin = "username", formUriBasicAuthPassword = "password",

Now everything works as before.

Thanks for the help. Appreciate for you quick response.
@andreag85 @william-ferguson-au @F43nd1r

@william-ferguson-au - add this to your acra/cloudant wiki. So others will be aware of it.

@william-ferguson-au
Copy link
Member

@raviteja06 why don't you add it to the ACRA wiki.

@raviteja06
Copy link

@william-ferguson-au wiki updated. You can close this ticket.

@william-ferguson-au
Copy link
Member

Thanks

On Fri, 26 Feb 2016, 4:45 PM Ravi Gadipudi notifications@github.com wrote:

@william-ferguson-au https://github.com/william-ferguson-au wiki
updated. You can close this ticket.

—
Reply to this email directly or view it on GitHub
#376 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@william-ferguson-au @andreag85 @raviteja06 @F43nd1r