I working on UPnP device implementation in iOS and I have downloaded the source code from here. Using the sample I am able to discover the UPnP devices on the network but when I try to fetch the description of the device I am getting an issue.I have not changed anything in the default code still I am getting this issue.
Request:
<?xml version="1.0" encoding="utf-8"?>
<s:Envelope s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
<s:Body><u:GetSortCapabilities xmlns:u="urn:schemas-upnp-org:service:ContentDirectory:1">
</u:GetSortCapabilities></s:Body></s:Envelope>
Response:
Error (SoapAction): Got a non 200 response: 500. Data:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body><SOAP-ENV:Fault><faultcode>SOAP-ENV:Client</faultcode>
<faultstring>UPnPError</faultstring><detail>
<u:UPnPError xmlns:u="urn:schemas-upnp-org:control-1-0">
<u:errorCode>801</u:errorCode>
<u:errorDescription>Access denied</u:errorDescription>
</u:UPnPError></detail>
</SOAP-ENV:Fault></SOAP-ENV:Body></SOAP-ENV:Envelope>
Can anybody suggest me how to resolve this?
Not sure if this will fix your problem, but just a couple days ago, I discovered that the default newline in windows is "\r\n" (ascii 13 and 10) and the default newline in iOS is "\n" (ascii 10 only).
This caused some UPnP implementations to NOT respond to my search requests. The UPnP Standard requires "\r\n" in general for a newline. You may want to look at the actual bytes and see if 13 and 10 are always together, or if you're only getting the 10.
Related
I use twilio to share contact information of my users. I've been doing this for 6 months with no problems.
Recently, I started receiving bug reports that the contact card isn't coming through. iOS is receiving it as an unknown attachment with a file name such as 'text_0.x-vcard' [see screenshot]
I'm unable to reproduce this on my device - I've received reports of this from users with an iPhone 7, iPhone 6, and iPhone 5 - nothing consistent. No consistency in OS either. The vcf file is valid, and it works for 90% of users.
Any ideas? Here is an example of a vcf file - works on my phone, doesn't work on one of the other devices.
BEGIN:VCARD
VERSION:3.0
N:Doe;John;;;
FN:John Doe
ORG:Example.com Inc.;
TITLE:Imaginary test person
EMAIL;type=INTERNET;type=WORK;type=pref:johnDoe#example.org
TEL;type=WORK;type=pref:+1 617 555 1212
TEL;type=WORK:+1 (617) 555-1234
TEL;type=CELL:+1 781 555 1212
TEL;type=HOME:+1 202 555 1212
item1.ADR;type=WORK:;;2 Enterprise Avenue;Worktown;NY;01111;USA
item1.X-ABADR:us
item2.ADR;type=HOME;type=pref:;;3 Acacia Avenue;Hoemtown;MA;02222;USA
item2.X-ABADR:us
NOTE:John Doe has a long and varied history\, being documented on more police files that anyone else. Reports of his death are alas numerous.
item3.URL;type=pref:http\://www.example/com/doe
item3.X-ABLabel:_$!<HomePage>!$_
item4.URL:http\://www.example.com/Joe/foaf.df
item4.X-ABLabel:FOAF
item5.X-ABRELATEDNAMES;type=pref:Jane Doe
item5.X-ABLabel:_$!<Friend>!$_
CATEGORIES:Work,Test group
X-ABUID:5AD380FD-B2DE-4261-BA99-DE1D1DB52FBE\:ABPerson
END:VCARD
Steph,
I'm new to Stack Exchange, so I don't know how else to send this. You show one of your Twilio numbers above.
I am seeing similar issues, and I believe it is all related to your content type. Try a
curl --head <your vcard web address>
The only time I've had it work for me is when the it returned
Content-Type: text/x-vcard; charset=utf-8; name="fileName.vcf"
I don't know how long this link will last but try sending this vcard VCF File (Send from http address), it works for me on Twilio w/ iOS 10.3.3
I think your right about it being related to security; why would you want a 'text/html' file being being executed like a 'text/x-vcard' file. I don't think internal header modifiers will work, let me know.
So currently working on a project and experiencing a strange issue with the ios version of Safari involving the playback of an audio file from a server.
I'm currently facing the following issue:
Person comes onto the page which has a standard html5 audio tag, and a direct link to the audio file for downloading purposes.
Person tries to listen to audio from audio tag, content plays for x number of minutes, cuts off then repeats (the x number of minutes is NOT the length of the recording, and is not consistent).
Person tries direct link of recording, rather then downloading the recording, Safari appears to go to a new page and wraps the download url in a video element, and the same issue as step 2 occurs.
Now the audio file is served up via a java scriptlet, which serves the file with the following code snippet:
String fn = saveTo + file_name;
f = new File(fn);
String fname = f.getName();
String contentType = "audio/wav";
if(fname.endsWith("mp3")){
contentType = "audio/mp3";
}
response.setContentType(contentType);
response.setHeader("Content-Transfer-Encoding", "binary");
response.setHeader("Content-disposition", "attachment;filename="+f.getName());
response.setHeader("Content-Length", ""+f.length());
FileInputStream fin = null;
try{
fin = new FileInputStream(f.getCanonicalFile());
byte[] data = new byte[1024];
int x = 0;
while((x = fin.read(data, 0, 1024))>=0){
response.getOutputStream().write(data, 0, x);
Thread.sleep(1);
}
} finally {
if(fin != null) {
try{
fin.close();
}catch(Exception ex){}
}
}
Now I know the code isn't the best by any measure, it isn't my code, and we're obviously working on the assumption that the file is found.
I'm finding when debugging on the iPhone with debug mode on a mac, it doesn't seem to show a return status code. It shows no response headers but it obviously must be receiving something. The server log seems to think its returning a status 200, this showing in Chrome and Firefox.
The code above appears to work fine with Chrome, and Firefox, but not Safari.
The only thing I am guessing is it has something to do with how the file is being pushed to the output stream that Safari isn't liking, or maybe its getting confused and should have a different status code. I've been banging my head against this for a good few days, and reading as much as I can about Safari, though most of the documentation I'm finding is on its "unique" implementation of web audio, and the use of a single channel which seems to be irrelevant to this.
Any Help would be appreciated.
I experienced the same issue with Safari on iOS, and after a lot of debugging, I found the issue was related to the combination of headers applied to the response.
My application is C#-based, but this solution should be platform independent (because as previously stated, it is a response header issue).
Necessary Headers:
Content-Range: bytes 0-[content length]/[content length]
Content-Transfer-Encoding: binary
Content-Length: [content length]
Accept-Ranges: bytes
I devised this after inspecting a response from MP3s delivered via Akamai's content delivery service.
I use the distriqt scanner ane and it works very vell on iOS. But with the similar app on Android it crashes the app immediately (while calling Scanner.service.startScan( options ))
I got follwing from logcat:
E/QCOM PowerHAL( 313): Invalid hint ID.
E/mm-camera-intf( 313): mm_camera_open: opened, break out while loop
E/InputDispatcher( 858): channel '2da9ab5b air.myfunnyappidcovered/air.myfunnyappidcovered.AppEntry (server)' ~ Channel is unrecoverably broken and will be disposed!
E/InputDispatcher( 858): channel 'e01d279 air.myfunnyappidcovered/com.distriqt.extension.scanner.zbar.ZBarScannerActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
Any Idea? All permissions and permission-freatures are set. The AS-Code works, like the iOS-compile shows. Tested with the same result on different Android-devices.
I have a strange error occurring only on safari for iPads. I've added a youtube iframe element to the page that looks like this.
<iframe width="560" height="315" src="http://www.youtube.com/embed/dDAB35SYIr0?rel=0" frameborder="0" allowfullscreen></iframe>
As you can see I say the source is http and my site is http as well. Now on iPad Safari I get this console error message
Blocked a frame with origin "https://www.youtube.com" from accessing a
frame with origin "http://example.com". The frame requesting access
has a protocol of "https", the frame being accessed has a protocol of
"http". Protocols must match.
I think this is weird for two reasons
1. I specifically say "use http"
2. It works on other devices
Now if I change the protocol to https (now I'm on a https site as well) and try this, I get this error instead
Blocked a frame with origin "https://www.youtube.com" from accessing a
frame with origin "https://www.example.com". Protocols, domains, and ports
must match.
All errors references the html5player.js file.
How can I solve this?
Thanks for your help
Ok, so it seems webkit on IPad has a bug, a weird one. I read it here -> https://tmpworldwide.github.io/bugs/ios-tappy-bug.html
I'll quote a bit of it
Applying the :active pseudo-class to a universal selector (*) and including a property of -webkit-tap-highlight-color seems to be the culprit.
*:active {
-webkit-tap-highlight-color: tomato;
}
Now, here is the strange part. The bug is only triggered when the above CSS block is present and there is an input element present on the page with a type attribute value of "search". I know, crazy, right?
Another oddity here is that when you apply focus to the search input, type something in, and then attempt to play video, it will then work.
The solution for now is to change to input type="search" to input type="text".
I need to compress data sent over a secure channel in my iOS app and I was wondering if I could use TLS compression for the same. I am unable to figure out if Apple's TLS implementation, Secure Transport, supports the same.
Does anyone else know if TLS compression is supported in iOS or not?
I was trying to determine if Apple implementation of SSL/TLS did support compression, but I have to say that I am afraid it does not.
At first I was hopeful that having a errSSLPeerDecompressFail error code, there has to be a way to enable the compression. But I could not find it.
The first obvious reason that Apple doesn’t support compression is several wire captures I did from my device (6.1) opening secure sockets in different ports. In all of them the Client Hello packet reported only one compression method: null.
Then I looked at the last available code for libsecurity_ssl available from Apple. This is the implementation from Mac OS X 10.7.5, but something tells me that the iOS one will be very similar, if not the same, but surely it will not be more powerful than the Mac OS X one.
You can find in the file sslHandshakeHello.c, lines 186-187 (SSLProcessServerHello):
if (*p++ != 0) /* Compression */
return unimpErr;
That error code sounds a lot like “if the server sends another compression but null (0), we don’t implement that, so fail”.
Again, the same file, line 325 (SSLEncodeClientHello):
*p++ = 0; /* null compression */
And nothing else around (DEFLATE is the method 1, according to RFC 3749).
Below, lines 469, 476 and 482-483 (SSLProcessClientHello):
compressionCount = *(charPtr++);
...
/* Ignore list; we're doing null */
...
/* skip compression list */
charPtr += compressionCount;
I think it is pretty clear that this implementation only handles the null compression: it is the only one sent in the Client Hello, the only one understood in the Server Hello, and the compression methods are ignored when the Client Hello is received (null must be implemented and offered by every client).
So I think both you and me have to implement an application level compression. Good luck.