Michael, On 2013-05-01 16:40, Michael McMahon wrote: > Another possibility if we were to do that in the future, could be: > > "GET,POST:Header1=value 1,Header2=value 2"
Variant with space looks more natural for me as it follows HTTP header syntax. But it's up to you to make a decision. -Dmitry > > - Michael > > On 01/05/13 12:38, Dmitry Samersoff wrote: >> Michael, >> >> Sorry for not being clean enough. >> >> On my opinion an ability to check header value as well as a header name >> is quite useful future for the real world. >> >> e.g. to being able to prevent redirection to other domain or limit >> certain content type etc. >> >> I understand, that these changes is out of scope of today work, but it >> quite possible that we implement it sometimes in a future. >> >> For (header-name: header-value) pair : (colon) is a native delimiter, >> so it's better not to use it to separate methods list and headers list. >> >> On my opinion, (space) is enough for this case and better reflect HTTP >> header i.e. >> >> "GET,POST Header1,Header2" >> >> -Dmitry >> >> >> >> On 2013-05-01 15:16, Michael McMahon wrote: >>> Ah right. The permission only contains header names. >>> It never contains header values. And header names are "tokens" >>> in the Http spec that cannot contain a colon character. >>> >>> Michael >>> >>> On 01/05/13 12:11, Dmitry Samersoff wrote: >>>> 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
