EMI real-time data POST and OPTIONS action

  • 419 Views
  • Last post 14 August 2018
  • Discussion is solved
PCLRA posted this 11 August 2018

Hey guys

I’m wondering if anyone would be able to help me diagnose where I’m going wrong with setting up a Real-time dispatch push from EMI.

Previously we had been using a GET action as/when required, but we’re now wanting to change that so EMI push real time dispatch data to our (new) endpoint.

We’ve configured our endpoint, tested it with dummy data, and we’re now trying to register our endpoint by POST’ing to EMI (based on what is outlined in the API Documentation for POST). However, each time we post to https://emi.azure-api.net/rtd/ we’ll either receive back a 204 “No content” (which is probably due to me trying a number of different ways of writing our endpoint URL) or more commonly a 500 “internal server error”.

I’ve repeated the process using the POST form / web-form on the EMI API site, and I’m getting similar errors as shown in the attached screen shots.

Any idea what’s going wrong?
(The same error is coming up with the OPTIONS action)

Attached files

  • Liked by
  • ensslen
Order by: Standard | Newest | Votes
Rachel Langford posted this 14 August 2018

The real time dispatch and the real time prices apis provide the following functions:

  • Get - this will get the latest data available
  • Post - use this to sign up for pushes of the latest data as they becomes available
  • Delete - remove your url from receiving data pushes

and

  • Options - see what subscriptions you already have - this will include the url that EMI will try and push data to, and the date of signup.

An issue has been identified with the Options function not returning the subscriptions, which has now been corrected, which will hopefully go some way to solving issues you are experiencing. 

Some common issues that can occur, will give the following result codes:

204 - No content - this occurs when the url submitted is empty, or it hasn't  been changed from the sample url provided in the "Try it" area. Note that the name/url for sign ups needs to be in the body of the request. 

304 - Not modified - this occurs if the user already has a subscription to this API. Use the options function to see what subscriptions you already have if this is what is occuring. If you need to change the url  that you would like to use, use the Delete option to delete your subscription, and then Post to re-sign up with the new url.

500 - Internal server error - if this occurs, please do continue to notify EMI, as something has gone awry.

 

  • Liked by
  • PCLRA
ensslen posted this 13 August 2018

I'm having the same trouble.  If I run the following

#!/bin/bash
curl -v -X POST "https://emi.azure-api.net/rtd/" \ -H "Ocp-Apim-Subscription-Key: ..." \ --data-ascii "{ \"name\" : \"PocoAWSDataLab\" , \"url\" : \"https://example.execute-api.ap-southeast-2.amazonaws.com/dev/rtd\" }"
curl -v -X POST "https://emi.azure-api.net/rtp/" \ -H "Ocp-Apim-Subscription-Key: ..." \ --data-ascii "{ \"name\" : \"PocoAWSDataLab\" , \"url\" : \"https://example.execute-api.ap-southeast-2.amazonaws.com/dev/rtp\" }"

I get this pair of 204 responses.  No call is ever made to the endpoints I supplied:

Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 104.210.84.32...
* TCP_NODELAY set
* Connected to emi.azure-api.net (104.210.84.32) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=*.azure-api.net
*  start date: Jan 11 18:29:16 2018 GMT
*  expire date: Jan 11 18:29:16 2020 GMT
*  subjectAltName: host "emi.azure-api.net" matched cert's "*.azure-api.net"
*  issuer: C=US; ST=Washington; L=Redmond; O=Microsoft Corporation; OU=Microsoft IT; CN=Microsoft IT TLS CA 4
*  SSL certificate verify ok.
> POST /rtd/ HTTP/1.1
> Host: emi.azure-api.net
> User-Agent: curl/7.54.0
> Accept: */*
> Ocp-Apim-Subscription-Key: ...
> Content-Length: 109
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 109 out of 109 bytes
< HTTP/1.1 204 No Content
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Length: 0
< Expires: -1
< Set-Cookie: ASP.NET_SessionId=xzhzz4ouwafxze1m023esaq0; path=/; HttpOnly
< X-AspNet-Version: 4.0.30319
< X-Powered-By: ASP.NET
< Date: Mon, 13 Aug 2018 01:36:47 GMT
<
* Connection #0 to host emi.azure-api.net left intact
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 104.210.84.32...
* TCP_NODELAY set
* Connected to emi.azure-api.net (104.210.84.32) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
*  subject: CN=*.azure-api.net
*  start date: Jan 11 18:29:16 2018 GMT
*  expire date: Jan 11 18:29:16 2020 GMT
*  subjectAltName: host "emi.azure-api.net" matched cert's "*.azure-api.net"
*  issuer: C=US; ST=Washington; L=Redmond; O=Microsoft Corporation; OU=Microsoft IT; CN=Microsoft IT TLS CA 4
*  SSL certificate verify ok.
> POST /rtp/ HTTP/1.1
> Host: emi.azure-api.net
> User-Agent: curl/7.54.0
> Accept: */*
> Ocp-Apim-Subscription-Key: ...
> Content-Length: 109
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 109 out of 109 bytes
< HTTP/1.1 204 No Content
< Cache-Control: no-cache
< Pragma: no-cache
< Content-Length: 0
< Expires: -1
< Set-Cookie: ASP.NET_SessionId=chpp1yhzyefz0ikolz1z4uzx; path=/; HttpOnly
< X-AspNet-Version: 4.0.30319
< X-Powered-By: ASP.NET
< Date: Mon, 13 Aug 2018 01:36:48 GMT
<
* Connection #0 to host emi.azure-api.net left intact

PCLRA posted this 14 August 2018

Hi Rachel,

A big thank you to you and your team.
I can confirm that both the OPTIONS and POST actions are now working as intended, and I have been able to register our API endpoint.

Thanks again guys

ensslen posted this 14 August 2018

The 204 error results from failing to specify content-type in the header.  The documents say content-type is optional, but the call doesn't work without the content type.

"Content-Type: application/json"

Close