After some more research in addition to my allready opened Thread in the Help section (seems not to be used too often I think) I found some more problems with the UPnP stack. The Intel Tools seems to try to load the Icon file and this failes. After some code reading and manual tests I found that there seems to be no support for any files in the HTTP Server at all. So only the description xml files are supported but not any other files .
See Device.java -> I can't find a way how any files (like icon.gif) are treated here?
The method httpGetRequestRecieved is invoked from the method httpRequestRecieved which is invoked as callback from the HTTPServerThread, and the default implementation is to handle only UPnP command.
If you want to change the default behavior you have to create a Device like this:
public class HTTPServerWebDevice extends Device {
public void httpRequestRecieved(HTTPRequest httpReq){
super.httpRequestRecieved(httpReq);
String uri = httpReq.getURI();
if (uri.startsWith(ICON_URI) == false) return;
byte buf[];
try {
int len = (int)(new File(uri).length());
FileInputStream fis = new FileInputStream(uri);
buf = new byte[len];
fis.read(buf);
} catch (IOException e) {
return;
}
HTTPResponse httpRes = new HTTPResponse();
httpRes.setContentType("image/gif");
httpRes.setStatusCode(HTTPStatus.OK);
httpRes.setContent(buf);
httpReq.post(httpRes);
}
}
For the other post on the Help Forum do you continue to have problem or everything is working now?
Ciao,
Stefano "Kismet" Lenzi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the hint, I checked this with the LightDevice example and it improves the situation a little bit but in an invalid way. If you overwrite the HTTPRequestReceived method and call the super implementation, there will allways be sent a BadRequest result on HTTP by the super implementation and just afterwards the resulting Icon file by the own implementation.
Therefore I think the Device implementation must be adapted directly to support this case (either to not send a BadRequest result or to handle any kind of files requested directly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
>If you overwrite the HTTPRequestReceived method and call the super implementation, there will allways be sent a
>BadRequest result on HTTP by the super implementation and just afterwards the resulting Icon file by the own
>implementation.
>Therefore I think the Device implementation must be adapted directly to support this case (either to not send a >BadRequest result or to handle any kind of files requested directly.
Yes I think that could be reasonable to allow the device to automatically send the Icon. Would you mind to open a feature request?
Ciao,
Stefano "Kismet" Lenzi
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After some more research in addition to my allready opened Thread in the Help section (seems not to be used too often I think) I found some more problems with the UPnP stack. The Intel Tools seems to try to load the Icon file and this failes. After some code reading and manual tests I found that there seems to be no support for any files in the HTTP Server at all. So only the description xml files are supported but not any other files .
See Device.java -> I can't find a way how any files (like icon.gif) are treated here?
private void httpGetRequestRecieved(HTTPRequest httpReq)
{
String uri = httpReq.getURI();
Debug.message("httpGetRequestRecieved = " + uri);
if (uri == null) {
httpReq.returnBadRequest();
return;
}
Device embDev;
Service embService;
byte fileByte[] = new byte[0];
if (isDescriptionURI(uri) == true) {
String localAddr = httpReq.getLocalAddress();
fileByte = getDescriptionData(localAddr);
}
else if ((embDev = getDeviceByDescriptionURI(uri)) != null) {
String localAddr = httpReq.getLocalAddress();
fileByte = embDev.getDescriptionData(localAddr);
}
else if ((embService = getServiceBySCPDURL(uri)) != null) {
fileByte = embService.getSCPDData();
}
else {
httpReq.returnBadRequest();
return;
}
HTTPResponse httpRes = new HTTPResponse();
if (FileUtil.isXMLFileName(uri) == true)
httpRes.setContentType(XML.CONTENT_TYPE);
httpRes.setStatusCode(HTTPStatus.OK);
httpRes.setContent(fileByte);
httpReq.post(httpRes);
}
Hi Kusis,
The method httpGetRequestRecieved is invoked from the method httpRequestRecieved which is invoked as callback from the HTTPServerThread, and the default implementation is to handle only UPnP command.
If you want to change the default behavior you have to create a Device like this:
public class HTTPServerWebDevice extends Device {
public void httpRequestRecieved(HTTPRequest httpReq){
super.httpRequestRecieved(httpReq);
String uri = httpReq.getURI();
if (uri.startsWith(ICON_URI) == false) return;
byte buf[];
try {
int len = (int)(new File(uri).length());
FileInputStream fis = new FileInputStream(uri);
buf = new byte[len];
fis.read(buf);
} catch (IOException e) {
return;
}
HTTPResponse httpRes = new HTTPResponse();
httpRes.setContentType("image/gif");
httpRes.setStatusCode(HTTPStatus.OK);
httpRes.setContent(buf);
httpReq.post(httpRes);
}
}
For the other post on the Help Forum do you continue to have problem or everything is working now?
Ciao,
Stefano "Kismet" Lenzi
Thanks for the hint, I checked this with the LightDevice example and it improves the situation a little bit but in an invalid way. If you overwrite the HTTPRequestReceived method and call the super implementation, there will allways be sent a BadRequest result on HTTP by the super implementation and just afterwards the resulting Icon file by the own implementation.
Therefore I think the Device implementation must be adapted directly to support this case (either to not send a BadRequest result or to handle any kind of files requested directly.
>If you overwrite the HTTPRequestReceived method and call the super implementation, there will allways be sent a
>BadRequest result on HTTP by the super implementation and just afterwards the resulting Icon file by the own
>implementation.
Oops you should invoke the only after that you checked that the requested is not Icon file...
Please check the CyberLink Developer Documentation (even if a bit outdated) https://sourceforge.net/project/showfiles.php?group_id=75638&package_id=76172&release_id=330743
>Therefore I think the Device implementation must be adapted directly to support this case (either to not send a >BadRequest result or to handle any kind of files requested directly.
Yes I think that could be reasonable to allow the device to automatically send the Icon. Would you mind to open a feature request?
Ciao,
Stefano "Kismet" Lenzi
Done with feature request 1864437
Thanks
Markus