I have perl on apache http service that's been working fine for several years to issue sonos cmds and receive callbacks. About two weeks ago, I stopped receiving any callbacks.
I subscribed successfully (response={}) for groupVolume, playbackMetadata, and playback events.
I am successfully getting webhook messages from other services (e.g., Vonage) using https, so it seems the port is open to my server, and apache is successfully processing these requests. I see no trace of any messages from the sonos api in my apache logs.
I have no trouble issuing commands (setMute, getFavorites, getPlaybackMetadata, etc.). Only the callbacks are a problem.
I ran the ssltools checker from digicert but found no issues.
I can't recall making any changes to the home router config.
Does anyone else have a problem like this or know how to diagnose what's happening?
I installed WireShark but am overwhelmed with the functionality and don't know how to narrow down what I should be looking for to see if the messages are being received and blocked somehow.
it may be unlikely, but is it possible that there isn't any usage of your integration that would result in callbacks being sent to your service? For example - if volume isn't being changed, or playback isn't happening, you won't receive events.
If that's not the case, additional information is required to debug this issue. Could you please email developer-feedback#sonos.com with the following information:
The name of your service/application
The date/time your service stopped receiving callback events. You said about two weeks ago, but could you be more specific?
The clientId used by your code. This is the UUID you generated when you initially created the "API Key" on developer.sonos.com. Format is xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (note - we do not need the secret associated with this key).
With that information we should be able to determine the cause of your missing callbacks.
Related
Without getting into much detailed code
I have an 'kiosk' application that is running in about 500-800 different 'kiosk' at about 50 locations. Very simple application that connects to internet via a Verizon MIFI (2-3 MIFI per location). We believe that Verizon has made some changes to the network and now randomly I get
The request failed with HTTP status 417: Expectation failed
I have viewed The request failed with HTTP status 417: Expectation Failed - Using Web Services
and FB Connect: (417) Expectation failed
But you see I already had used
System.Net.ServicePointManager.Expect100Continue = false
in my code.
So one of the issues I have is the application isn't easy to test, and it will fail for 20-30 minutes or several days, then clears itself up.
Changing the config to include
<system.net>
<settings>
<servicePointManager expect100Continue="false" />
</settings>
Would be a large task, I don't know it that would even fix it. Since it is random I'm having troubles because I typically can't get it to fail in my office at my desk more than 1 time.
I happen to use VB and .Net for the application and services that run with the 'kiosk'.
The issue seems to be with the config on the mifi and not the Verizon network itself. We recently switched APNs and when a mifi connects to the Verizon network it is supposed to update automatically. Sometimes the mifi will fail to update the APN setting and that is when we get this error message. There are two ways I have found to fix this issue. The first and easier is to log into the mifi and manually update the setting. If you are dealing with a user who is not tech savvy and walking them through logging into the mifi will not work you can call the Verizon wireless enterprise help desk and have them remove the feature set from the mifi, add the features back, and then pull the battery from the mifi and power cycle it, this will make the mifi request the configuration settings again.
I’m trying to get a mod_perl2 application ported to AWS. As part of the port I thought I’d move from Debian Squeeze to Wheezy with the latest stable mod_perl & Apache2 combination.
The application works right up to the point I try and write JSON responses to the client. At this point, each request is canceled on the client and on the server I get the error
Apache2::RequestIO::print: (103) Software caused connection abort
whenever I write to the client, i.e.:
$self->req->print($output);
I’ve tried tcpdumping the response to the client, and I can see it being written out, but no response is received on the client end and it just barfs chips. I can’t find any information on how to get around this.
I found quite a few people asking about this question on the net without many answers. The solution to my problem was very specific but I thought I’d post what I did anyway, it may help someone.
The client was canceling the request before the response was fully written, which was crapping out Apache::RequestIO (for reasons I still don’t know).
I couldn’t work out why I was seeing this behavior.
By using tcpdump I could see that data was being written out to the client – and it looked fine.
By inspecting the page in Chrome and looking at the network stack, I could see that my request for data was being canceled after no response was received (which was odd because the code worked fine on other servers and I could see the response was being written). Debugging was may harder because with Apache crashing out with an error in print IO I couldn’t check if the bytes written equaled the bytes of data. I wasn’t sure if something was getting stuck on the server side.
So, I changed the Content-Type of the response from application/json to text/html, so that I could query the page and just look at the actual response as text. Once I did that, I could see that the response was fine.
I started to look for other causes, and I found that in the migration to the new server, I’d missed altering some URLs in the DB to point to the new server, which meant my application was trying to get some data from the old DB.
This in turn was causing a load of timing issues, which was causing my problems. Once I fixed the config, the problems went away.
I setup my push queue endpoint as POST /iron, which works fine. But I'm getting a bunch of other requests too. Are these from Iron.io? What's the point of them? They're just filling up my Apache log. My server is returning 500 errors for all of them (500 instead of 404 in development mode).
POST /webhooks
POST /orders/webhook
POST /api/orders/webhook
Edit: I looked into it using multicast and noticed only my first server was getting these weird requests. They seem to be totally unrelated to iron.io. I guess it's just coincidence they're webhook requests and I just noticed them now. Probably someone put my server as an endpoint for their webhooks. >_<
If you added all those endpoints (subscribers) to your queue it's possible that IronMQ sends multiple requests. Check your queue's subscribers list.
GET /projects/{Project ID}/queues/{Queue Name}
If it contains multiple endpoints and its type is multicast - this is the reason of multiple requests on your side. In this case remove all odd subscribers (or setup new queue).
DELETE /projects/{Project ID}/queues/{Queue Name}/subscribers
In other case contact support ( :
More information at http://dev.iron.io/mq
IronMQ won't send any "unknown" requests. If your endpoint doesn't return a 200, the push queue will keep retrying the message until it either a) receives a 200, or b) fails the "max_retries" number of times.
Also per Featilion's answer, check the multicast/unicast/subscriber setup as well. If you are getting requests to those other endpoints then there's something up with your subscriber setup.
Feel free to jump into live chat if you don't figure out your answer rather quickly.
I am using a java raw HTTP client to connect to Shopify API (specifically, using Play Framework with the non-defualt sync driver which is actually the JDK's default driver).
My application usually manages to connect successfully and convert the temporary access token into a permanent one by calling the /admin/oauth/access_token endpoint.
However, sometimes I get this error result from the API:
Generic Error(400)
{"error":"invalid_request"}
I haven't been able to reproduce the issue with my test stores - I've tried installing a fresh store, reinstalling existing stores after uninstalling, I'm not sure why this call sometimes fail and how to debug it. The API call still continues to succeed for some stores using our application.
Some things that I am doing:
Even if the URL of the store is on a custom domain, I'm always using the https://foo.myshopfiy.com/admin/oauth/access_token URL and not the URL of the custom domain, to prevent a redirect.
I am always using an https URL and never an http one, again to prevent a redirect (we noticed a few issues with redirect with the Java HTTP client, so we aim to have zero redirects)
A thread I found about this error suggest possible problems with our SSL certificates, however I don't think this is my problem because some requests work for us, and the result of running openssl on our machine does't show any issues.
How should I proceed? Open a support ticket with Shopify?
FYI, I see that this specific problem only started yesterday on Feb 19 2013, so it might be a temporary issue.
FYI, the problem was caused by reusing a temporary access code.
Our fault - Shopify could have been more clear in their error message though.
I have a WCF service that has been working flawlessly for 3 months. It is consumed by local clients on the same server hosting the WCF service and local network clients. It uses SSL and basic authentication for security.
A few nights ago, the local client (local network clients not affected) started receiving 404 errors whenever it tried to use the service. I am able to open a browser on the server hosting the WCF and view the WSDL and even call the "put" command and get the expected "method not allowed". I have confirmed that no software or hardware changes have been made to the hosting server. I have confirmed that the SSL key is valid. I have confirmed that the permissions for the Application Pool are sufficient. I have confirmed that no firewall is running. The only thing odd is the IIS log showing that the first post does not contain the basic authentication user. However, the next line in the log does and shows a 200 response. I am not entirely sure that log is not normal. See below. I was hoping somebody could give me another place to research to find the problem. Please let me know.
2010-08-28 10:30:03 192.168.100.100 POST /protected/Service_Name_Here.svc/put - 443 - 192.168.100.100 - 401 2 5 2
2010-08-28 10:30:03 192.168.100.100 POST /protected/Service_Name_Here.svc/put - 443 User_Name_Here 192.168.100.100 - 200 0 0 5
EDIT: The local client that is throwing the error is transferring large files to the WCF service. The local network clients are transferring small files and not throwing the error. I found this link that suggests that the default transferMode="Buffered" will throw a 404 for files above 20 MB file. The fix for this person was to change the transferMode="Streamed". However, the "Streamed" setting only allows 1 parameter to be passed to the WCF service. I have multiple parameters so I need to find a fix for "buffered" mode.
The fix for this person was to change the transferMode="Streamed". However, the "Streamed" setting only allows 1 parameter to be passed to the WCF service. I have multiple parameters so I need to find a fix for "buffered" mode.
Sounds like that's the correct fix, however the caveat is that streamed mode requires custom message contracts; you can't use the "RPC" style that WCF pushes as a default for operations. If you need to provide more than one parameter in a streamed mode transfer, simply add them to your custom message contract.
Here's a nice discussion on the subject from Microsoft.
If you have problems with message size be aware that there are 3 levels of configuring accepted request size for IIS:
WCF - default max message size 65KB (maxReceivedMessageSize)
ASP.NET runtime hosting WCF - default max request size is 4MB (maxRequestLength)
IIS 7 with request filtering installed - default max request size about 28MB (maxAllowedContentLength)
If WCF rejects your message you will probably get meaning full error but for ASP.NET and IIS you will get exactly HTTP 404.
Streaming will not help you unless you change your operations.