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 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
