Error using client on https://sqrljava.com

  • New Wordpress Plug-In Forum
    Guest:

    Just a note that we have a new forum to contain discussions relating to the Wordpress plug-in which Daniel Persson originated and has been making great progress on. You'll find it under "Server-Side Solutions."

    /Steve.

daveb

Member
Jul 29, 2018
11
1
Hi Jeff -
I'm getting the following error when I try to use the iOS client on https://sqrljava.com

Response body is not application/x-www-form-urlencoded
(this message pops up on the iphone)

I don't see much on my end, can check on your side?

Thanks!
Dave
 

Jaap

Well-known member
May 20, 2018
96
13
Dude this one is sooo obvious:
A POST to

returns these headers:
Code:
HTTP/1.1 200 
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: 695
Date: Wed, 10 Jul 2019 20:37:04 GMT
Jeff expects Content-Type: application/x-www-form-urlencoded
 

daveb

Member
Jul 29, 2018
11
1
Dude this one is sooo obvious:
Why would Jeff expect x-www-form-urlencoded for the Content Type response header?
x-www-form-urlencoded is used to POST data and is used in a request header

All the other SQRL clients (including Steve's) accept text/plain;charset=utf-8. Not sure if it's called out in the SQRL spec (if it's even published yet)
 

Steve

Administrator
Staff member
May 6, 2018
992
290
www.grc.com
@daveb : Jeff's client is being a bit more rigorous than others, but it's not incorrect. All SQRL server responses are in www-form-urlencoded format -- just like an HTTP POST form submission. Since text/plain is a superset of www-form-urlencoded, that's not wrong either. But it might be that within the iOS platform framework, he's using a built-in function to retrieve and parse the server's returned data which expects the Content-Type to be formally declared as expected.
 
  • Like
Reactions: kalaspuffar

Jaap

Well-known member
May 20, 2018
96
13
Perhaps we should explicitly choose a Content-type and put it in the spec?
 

daveb

Member
Jul 29, 2018
11
1
@Steve Thanks for chiming in

iOS isn't enforcing x-www-form-urlencoded on a response, I suspect it is Jeff's code

<gets on soapbox>
While I see what are saying about the raw format of the response, www-form-urlencoded as the response content type is unorthodox at best. Consider the following:
* In my 20+ years of web programming, I've only seen content type www-form-urlencoded in an HTTP request; never on a reponse.
* It has form in the name, as it is intended to be used in a form POST on an HTTP request, not a response.
* A quick google search shows it used in various RFCs (6750, 8058) as HTTP request content type in a form POST, not on a reponse. I admit this was not an exhaustive search :)
<gets off soapbox>

Technically, you can use any mime type for anything, as long as all parties involved understand the semantics.

In your reply you mention that "Jeff's client is being a bit more rigorous than others, but it's not incorrect." and "Since text/plain is a superset of www-form-urlencoded, that's not wrong either". Both of these cannot be true, we need agreement that one or both are acceptable

I'd like to see the expected mime type(s) for the SQRL server reply explicitly defined in your new SQRL spec doc.
You could even add a third mime type that is custom for SQRL (x-sqrl-urlencoded, etc), but then that's more work for the existing implementations to catch up, so maybe that's better left for SQRL 2.0.

Look forward to clearing this up and moving forward in whichever way you decide is best.

One final thought. On many projects, when it comes to ambiguities such as this, the reference implementation dictates behavior. Therefore if the GRC SQRL client accepts text/plain, all clients should. Our situation is a little different, as you are still documenting the SQRL spec, so you have a choice. But once the SQRL spec is finalized, I suggest we continue to use the standard reference implementation model to resolve ambiguities.
 

Jeffa

Well-known member
May 20, 2018
133
49
@Steve Thanks for chiming in

iOS isn't enforcing x-www-form-urlencoded on a response, I suspect it is Jeff's code

<gets on soapbox>
While I see what are saying about the raw format of the response, www-form-urlencoded as the response content type is unorthodox at best. Consider the following:
* In my 20+ years of web programming, I've only seen content type www-form-urlencoded in an HTTP request; never on a reponse.
* It has form in the name, as it is intended to be used in a form POST on an HTTP request, not a response.
* A quick google search shows it used in various RFCs (6750, 8058) as HTTP request content type in a form POST, not on a reponse. I admit this was not an exhaustive search :)
<gets off soapbox>

Technically, you can use any mime type for anything, as long as all parties involved understand the semantics.

In your reply you mention that "Jeff's client is being a bit more rigorous than others, but it's not incorrect." and "Since text/plain is a superset of www-form-urlencoded, that's not wrong either". Both of these cannot be true, we need an agreement that one or both are acceptable

I'd like to see the expected mime type(s) for the SQRL server reply explicitly defined in your new SQRL spec doc.
You could even add a third mime type that is custom for SQRL (x-sqrl-urlencoded, etc), but then that's more work for the existing implementations to catch up, so maybe that's better left for SQRL 2.0.

Look forward to clearing this up and moving forward in whichever way you decide is best.

One final thought. On many projects, when it comes to ambiguities such as this, the reference implementation dictates behavior. Therefore if the GRC SQRL client accepts text/plain, all clients should. Our situation is a little different, as you are still documenting the SQRL spec, so you have a choice. But once the SQRL spec is finalized, I suggest we continue to use the standard reference implementation model to resolve ambiguities.
Hi,

It "sort of" implies it here. https://www.grc.com/sqrl/protocol.htm
Steve's server asserts it and always has.

I think I added the check a while back as someone's server implementation was sending me application/json

I suppose I should be rigorous in what I put out onto the network and liberal in what I accept.

Jeff
 

daveb

Member
Jul 29, 2018
11
1
Steve's server asserts it and always has.
Good point Jeff. I updated my beta site to use www-form-urlencoded when it sees the iOS client; as soon as I get the test flight link on my iphone I'll test it out.
I'll likely take my own advice about reference implementations, and switch to www-form-urlencoded in all cases.
 

daveb

Member
Jul 29, 2018
11
1
I received the confirmation email on Saturday and clicked the confirm link. I can see I'm subscribed to the list. But I have received a test flight access code email. Am I missing something?