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
Why would Jeff expect x-www-form-urlencoded for the Content Type response header?Dude this one is sooo obvious:
Hi,@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.
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.Steve's server asserts it and always has.