On ter?a-feira, 19 de julho de 2016 14:29:48 PDT Abhishek Sharma wrote: > > XML parsers are not very difficult to write, even for small, constrained > > implementations. Yes, they mean extra code for the constrained device, but > > I would say it's far more likely to produce a usable functionality than > > constraining the remote service to JSON that can be converted to the > > current use of CBOR that we do (for example, arrays limited to 3 levels > > of depth). I'm sorry, any solution that doesn't include support for other > > content types is flawed and shouldn't be accepted. > > You seem to have got a flawed idea of things that we are trying to achieve > with Proxy. Primary idea is to aid constrained OCF clients to access vast > amount of information available via popular web services like weather, > tumbler, geolocation etc and I find it hard to find ones that don't support > JSON. By not aiding in conversion, we will force constrained clients to > essentially have other types of parser. Not to mention that HTTP server's > can choose to respond with the format that they support rather than the one > constrained clients can handle. Will the constrained clients have robust > parsing mechanisms to handle malformed responses ? Will they be able to > handle response formats that they don't understand ?
Hello Abishek Obviously the client was designed to work with that particular server, so the developers did check the response formats and made sure that it worked. Sure, there's a danger that the response format changes or is simply corrupt. But think of this usecase: a client may want to download a firmware update. That's definitely not JSON. I think there's value in converting, like you're proposing. But this should be a secondary and optional functionality. So please move it to a second commit on top of the first. The first commit must implement the proxy without conversion; the second adds the functionality of translation, which must be triggered by the OCF client device. > > Indeed. But that can be solved in two ways: > > 1) move the fuctionality to another CoAP port, which does proxying only, > >no OCF protocol. > > 2) send the content of the reply as a Byte Text payload. That is, one > >single "property". > > > > I think you should analyse whether either makes sense and figure out the > > one that violates RESTful requirements the least. > > Both are wrong. For first, the solution is for OCF devices, and not for new > category of proxy only clients. For second, a byte text payload is useless > until the content format is associated with it. if not specified, an HTTP > server may choose to respond with any of the data formats that it supports. If you're arguing about what goes in the HTTP headers of the requests as well as of the reply, then indeed those should be controlled and accessible by the client. There should be a way for the client to specify what content types it supports, plus maybe some extra headers that the HTTP service may require. The reply from the server should be conveyed in the reply packet too. > > Not acceptable. HTTPS support should be there in the first version. > > We must not release a version of this proxy without HTTPS, as that would > > make an incentive for people to depend on non-HTTPS functionality. > > Not sure what's the problem here. In first version OCF devices will be able > to access public http web services like openweather, geolocation etc (Many > don't really support or require https) and in the next version https would > be added. Adding which will not break existing functionality and using > https over http could be anytime decided by either client or http server. > In first version, sensitive resources will not be supported, other than > that I don't see any issue. The issue is that most of those services support HTTPS, even if they don't require it. Clients should use it if they can. In fact, everyone should use HTTPS every time they can, regardless of whether it's required or not. Either way, another point is that your design will change considerably from the version without HTTP. I don't want to do the work of reviewing twice. So please implement HTTPS. HTTPS support is mandatory. > > Then please do that homework and figure out what third party library to > > use. The choice must be of one that is well-known and established, > > routinely receives updates. > > I am not sure weather you have visited the developers page of current parser > and checked details before making an opinion. Please check > https://github.com/nodejs/http-parser . It does received routine updates, > is being used by many open source projects and is a fork of NGINX. That's an HTTP header-parser library, not an HTTP library. It does not implement the actual communication. I'm asking you to choose a library that implements HTTP and HTTPS, with either a working HTTP2 implementation or the indication that it will soon have one. > > Sorry, that's an excuse. Please move it to resource or out-of-tree and > > modify the IoTivity API so that your requirements can be met. > > Second, you're not writing a CoAP proxy. You've argued above as a > > justification for using CBOR only that you're writing an OCF resource > > that takes OCF payload and sends an OCF payload as a reply. If your > > argument for CBOR holds, then you do not need to follow any of the CoAP > > requirements for proxying, as your service is not a CoAP proxy. > > Or, alternatively, make it a real CoAP proxy, on a separate port from the > > OCF port. If you do that, you'll be able to manipulate the headers as you > > see fit, and you will be able to accept the headers the way the CoAP spec > > says you should. You'll probably need to interface with libcoap directly, > > not using the CA and RI layer, though. > > You are not making any sense. The service is actually a CoAP - Http proxy > which follows CoAP Spec: check: > (https://tools.ietf.org/html/rfc7252#section-10.1) and mappings > (https://tools.ietf.org/html/draft-ietf-core-http-mapping-12#section-7) How > doese using OCF resource model and CBOR as a payload format violates CoAP > specifications ? I again reiterate that this is a solution for OCF devices > and we dont want to create a new category of proxy only client devices. We're mixing things here. Anyway, I am accepting the argument from further above that this is not a generic CoAP proxy. That means it's a OCF service. By immediate conclusion, the Proxy-URI header is completely unnecessary and I do not want to see it in the code or anywhere else. The URI being obtained should be in the OCF payload. I also don't want to see any further references to RFC 7252 or to an IETF draft about HTTP mapping. We're not doing that. > Also I don't understand the need to rewrite CA, libcoap interaction etc. > just because you dont like the location of code ? Exactly. If you use libcurl, you won't have to. But either way, since this is a service, it MUST NOT be inside resource. If you can't do it from outside resource, it's one of the two cases: a) the API is limited and can be expanded to support your use-cases b) you're not supposed to do what you're trying to do -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center
