Michael, I'm just asking about replacing : (colon) to another character to be able to write something like:
permission java.net.HttpURLPermission "http://www.foo.com/-";, "GET Location: http://www.foo.com/*, Content-type: image/jpeg"; in a future -Dmitry. On 2013-05-01 15:04, Michael McMahon wrote: > On 01/05/13 11:09, Dmitry Samersoff wrote: >> Michael, >> >>> "GET,POST:Header1,Header2" >> Colon is a delimiter between http header and it's value. >> >> With this syntax we might have problems in a future if sometimes we will >> support different headers for different methods or add an ability to >> check header value as well. >> >> -Dmitry > > Dmitry, > > It would complicate the syntax a lot if you wanted to support > different headers for different methods. Would be a lot simpler > to just grant separate permissions for the two cases. Eg. > > grant { > permission java.net.HttpURLPermission "http://www.foo.com/-";, > "GET:Header1,Header2"; > permission java.net.HttpURLPermission "http://www.foo.com/-";, > "POST:Header3,Header4"; > }; > > Michael > >> On 2013-04-30 14:30, Michael McMahon wrote: >>> Hi Kurchi, >>> >>> I can include such an example easily. Eg: >>> >>> "GET,POST:Header1,Header2" >>> >>> means one permission that permits either GET or POST with either or both >>> of the two headers. If you wanted to restrict one set of headers to GET >>> and another set to POST, then that would require two different >>> permissions. >>> >>> - Michael >>> >>> On 30/04/13 00:40, Kurchi Hazra wrote: >>>> Hi Michael, >>>> >>>> From the documentation, it is not clear to me how to represent >>>> both request-headers and method list together in an actions string for >>>> two or more methods. (Say I have two methods GET and POST and I want >>>> to specify a request-headers list for each, how do I do it?) Maybe >>>> another example will help. >>>> >>>> Thanks, >>>> Kurchi >>>> >>>> On 4/29/2013 3:53 AM, Michael McMahon wrote: >>>>> On 28/04/13 09:01, Chris Hegarty wrote: >>>>>> In the main I link the new HttpURLPermission class. >>>>>> >>>>>> When reading the docs I found the references to "the URL" and "URL >>>>>> string" confusing ( it could be just me ). When I see capital 'URL' >>>>>> my mind instantly, and incorrectly, goes to java.net.URL. In all >>>>>> cases you mean the URL string given when constructing the >>>>>> HttpURLPermission, right? >>>>>> >>>>> Yes, that is what is meant. The class does not use j.n.URL at all, as >>>>> that would bring us back >>>>> to the old (undesirable) behavior with DNS lookups required for basic >>>>> operations like equals() and hashCode() >>>>> >>>>>> Another example is the equals method >>>>>> "Returns true if, this.getActions().equals(p.getActions()) and p's >>>>>> URL equals this's URL. Returns false otherwise." >>>>>> >>>>>> this is referring so a simple string comparison of the given URL >>>>>> string, right? This should be case insensitive too. Does it take >>>>>> into account default protocol ports, e.g. http://foo.com/ equal >>>>>> http://foo.com:80/ >>>>>> >>>>> The implementation uses a java.net.URI internally. So URI takes care >>>>> of that. >>>>> >>>>>> implies() makes reference to the URL scheme, and other specific >>>>>> parts of the URL. Also, the constructors throw IAE 'if url is not a >>>>>> valid URL', but what does this mean. Should we just bite the bullet >>>>>> and just say that URI is used to parse the given string into its >>>>>> specific parts? Otherwise, how can this be validated. >>>>>> >>>>> I originally didn't want to mention URI in the apidoc due to >>>>> potential confusion surrounding the use of URL in the permission >>>>> class name. But, maybe it would be clearer to be explicit about it, >>>>> particularly for the equals() behavior. >>>>> Otherwise we have to specify all of it in this class. >>>>> >>>>>> As for the additions to HttpURLConnection, what are the implications >>>>>> on proxies? Permissions, etc... >>>>>> >>>>> There's no change in behavior with respect to proxies. Permission is >>>>> given to connect to proxies implicitly >>>>> except in cases where the caller specifies the proxy through the >>>>> URL.openConnection(Proxy) api. >>>>> There are other unusual cases like the Http "Use Proxy" response. >>>>> Explicit permission is required >>>>> for that case also. >>>>> >>>>> Thanks! >>>>> >>>>> Michael >>>>> >>>>>> -Chris. >>>>>> >>>>>> On 04/26/2013 03:36 PM, Michael McMahon wrote: >>>>>>> Hi, >>>>>>> >>>>>>> The is the suggested API for one of the two new JEPs recently >>>>>>> submitted. >>>>>>> >>>>>>> This is for JEP 184: HTTP URL Permissions >>>>>>> >>>>>>> The idea here is to define a higher level http permission class >>>>>>> which "knows about" URLs, HTTP request methods and headers. >>>>>>> So, it is no longer necessary to grant blanket permission for any >>>>>>> kind >>>>>>> of TCP connection to a host/port. Instead a HttpURLPermission >>>>>>> restricts >>>>>>> access to only the Http protocol itself. Restrictions can also be >>>>>>> imposed >>>>>>> based on URL paths, specific request methods and request headers. >>>>>>> >>>>>>> The API change can be seen at the URL below: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/ >>>>>>> >>>>>>> In addition to defining a new permission class, HttpURLConnection >>>>>>> is modified to make use of it and the documentation change >>>>>>> describing this >>>>>>> can be seen at the link below: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~michaelm/8010464/api/blender.html >>>>>>> >>>>>>> All comments welcome. >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Michael. >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * Give Rabbit time, and he'll always get the answer
