none
Section=ResponseHeader Detail=CR must be followed by LF

    Question

  • I want to query the following API and parse the json response in the selected cells through PowerQuery for Excel 2010 (last version):

    https://api.mintpal.com/v1/market/summary/

    Unfortunately I get this error:

        The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF.

    I contacted the server owners, but they said it had something to do with DDOS protection since they moved their hosting. Is there anything I could try?

    Here is another API that doesn't work and sends the same error:

    https://www.bitstamp.net/api/ticker/

    • Edited by Fullhdpixel Wednesday, June 04, 2014 7:47 PM
    Saturday, May 31, 2014 9:03 PM

Answers

All replies

  • We debugged this a bit and it looks like they are using control characters in their cookie values. That's a violation of the HTTP spec. We're using .NET libraries to parse these web files so unfortunately there isn't a workaround.
    Monday, June 02, 2014 10:53 PM
  • Thanks a lot for your reply.

    It would be awesome if this worked again :)

    Tuesday, June 03, 2014 4:36 PM
  • Here is another API that doesn't work and sends the same error:

    https://www.bitstamp.net/api/ticker/

    Wednesday, June 04, 2014 7:47 PM
  • Out of curiosity, did they explain how a cookie with an illegal character value helps to protect against DDOS? I wasn't able to find any evidence on the internet that this is a known strategy for dealing with DDOS attacks.

    It would be nontrivial for us to change the current behavior because it doesn't happen in our own code, so it would basically require that we reimplement parts of the .NET framework.

    Thursday, June 05, 2014 1:35 PM
  • no, unfortunately not.

    I did some research too  and I think there should be an option to disable all these kind of problems.

    This for example:

    useUnsafeHeaderParsing="true"

    Thursday, June 05, 2014 1:40 PM
  • There are at least three problems with that:

    1) Ad hoc testing showed that this only disabled the check when actually parsing the header. When we subsequently built a WebHeaderCollection manually, the check still seemed to get enforced.

    2) Presumably, the check exists for a reason and not just because the .NET team likes to rigorously enforce open standards. We would have to go through a security review for such a change.

    3) The Power Query engine runs in contexts other than the Power Query Excel addin, and in those contexts we don't control the app.config. We would have to ask all of those downstream customers to make the same change, and that might not be something they're willing to do. Imagine, for instance, that you're using the hosted refresh feature in SharePoint Online. Your query runs just fine in your workbook on your local computer, but consistently fails to refresh in SharePoint because the refresh service hasn't made a similar configuration change.

    EDIT: I should add that we're as disappointed as you are that Power Query won't work in this case.

    Thursday, June 05, 2014 1:56 PM
  • okay, I just thought it would be possible to add this as an additional feature.
    Friday, June 06, 2014 6:33 PM