CONTENTS DELETED
The author has deleted this message.
|
Hi Milton, From the URL RFC (http://tools.ietf.org/html/rfc3986, relevant grammar attached below) it seems that 'https://' in indeed a valid path component. ZnUrl seems to remove empty segments (which '//' would be) but that is not correct according to the RFC (empty segments appear to be valid components of a URL path). An empty path segment is valid, as "path-absolute" in your case consists of multiple "'/' segment" sequences, where "segment" is allowed to be empty. Your should open a bug report for this. Max path = path-abempty ; begins with '/' or is empty / path-absolute ; begins with '/' but not '//' / path-noscheme ; begins with a non-colon segment / path-rootless ; begins with a segment / path-empty ; zero characters path-abempty = *( '/' segment ) path-absolute = '/' [ segment-nz *( '/' segment ) ] path-noscheme = segment-nz-nc *( '/' segment ) path-rootless = segment-nz *( '/' segment ) path-empty = 0<pchar> segment = *pchar segment-nz = 1*pchar segment-nz-nc = 1*( unreserved / pct-encoded / sub-delims / '@' ) ; non-zero-length segment without any colon ':' pchar = unreserved / pct-encoded / sub-delims / ':' / '@' unreserved = ALPHA / DIGIT / '-' / '.' / '_' / '~' pct-encoded = '%' HEXDIG HEXDIG sub-delims = '!' / '$' / '&' / ''' / '(' / ')' / '*' / '+' / ',' / ';' / '=' On 5 August 2017 at 03:16:16, milton mamani ([hidden email]) wrote:
|
In reply to this post by akevalion
Hi Milton,
> On 5 Aug 2017, at 03:15, milton mamani <[hidden email]> wrote: > > Hi to all > > I want to use the next instruction in my code > > response := ZnEasy get: 'https://archive.softwareheritage.org/api/1/origin/git/url/https://github.com/hylang/hy'. > response. > > The previous code works from command line or in a webbrowser, but I does not work with ZnEasy > Because it takes the previous link as: > a ZnRequest(GET /api/1/origin/git/url/https:/github.com/hylang/hy) > > Could you please tell me what can I do for this situation? > > Cheers, > Milton ZnUrl has indeed a problem parsing this URL. It skips empty path segments, we'll have to create an issue for that and we should try to fix it, maintaining current behaviour. The parser is hand written and has evolved a bit over the years, so it is a bit brittle. Seaside's WAUrl seems to have the same problem. It is funny that this only now comes up. Thanks for reporting it. Here is a workaround, by manually creating a ZnUrl object from its elementary components. ZnUrl new scheme: #https; host: 'archive.softwareheritage.org'; addPathSegments: #('api' '1' 'origin' 'git' 'url' 'https:' '' 'github.com' 'hylang' 'hy'); yourself. You can use this as follows. ZnUrl new scheme: #https; host: 'archive.softwareheritage.org'; addPathSegments: #('api' '1' 'origin' 'git' 'url' 'https:' '' 'github.com' 'hylang' 'hy'); retrieveContents. ZnEasy get: (ZnUrl new scheme: #https; host: 'archive.softwareheritage.org'; addPathSegments: #('api' '1' 'origin' 'git' 'url' 'https:' '' 'github.com' 'hylang' 'hy'); yourself). Regards, Sven |
With the following commits
=== Name: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.63 Author: SvenVanCaekenberghe Time: 25 August 2017, 4:51:26.632889 pm UUID: b81e01d1-f613-0d00-b8a2-b72f05cf217b Ancestors: Zinc-Resource-Meta-Core-SvenVanCaekenberghe.62 Adapt ZnUrl>>#parsePath: to allow for empty path segments (as would happen when 2 consecutive slash occur in it) - simplify some of the code Modify #testEncodedSlash and #testParsingEmpty in ZnUrlTests to follow the new behavior === Name: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.38 Author: SvenVanCaekenberghe Time: 25 August 2017, 4:51:43.080273 pm UUID: 4116fcd1-f613-0d00-b8a3-a70905cf217b Ancestors: Zinc-Resource-Meta-Tests-SvenVanCaekenberghe.37 Adapt ZnUrl>>#parsePath: to allow for empty path segments (as would happen when 2 consecutive slash occur in it) - simplify some of the code Modify #testEncodedSlash and #testParsingEmpty in ZnUrlTests to follow the new behavior === Empty path segments are allowed and your example will work. Since it returns JSON, I would suggest doing ZnClient new accept: ZnMimeType applicationJson; enforceAcceptContentType: true; contentReader: [ :entity | STONJSON fromString: entity contents ]; get: 'https://archive.softwareheritage.org/api/1/origin/git/url/https://github.com/hylang/hy'. > On 17 Aug 2017, at 18:51, Sven Van Caekenberghe <[hidden email]> wrote: > > Hi Milton, > >> On 5 Aug 2017, at 03:15, milton mamani <[hidden email]> wrote: >> >> Hi to all >> >> I want to use the next instruction in my code >> >> response := ZnEasy get: 'https://archive.softwareheritage.org/api/1/origin/git/url/https://github.com/hylang/hy'. >> response. >> >> The previous code works from command line or in a webbrowser, but I does not work with ZnEasy >> Because it takes the previous link as: >> a ZnRequest(GET /api/1/origin/git/url/https:/github.com/hylang/hy) >> >> Could you please tell me what can I do for this situation? >> >> Cheers, >> Milton > > ZnUrl has indeed a problem parsing this URL. It skips empty path segments, we'll have to create an issue for that and we should try to fix it, maintaining current behaviour. The parser is hand written and has evolved a bit over the years, so it is a bit brittle. Seaside's WAUrl seems to have the same problem. It is funny that this only now comes up. Thanks for reporting it. > > Here is a workaround, by manually creating a ZnUrl object from its elementary components. > > ZnUrl new scheme: #https; host: 'archive.softwareheritage.org'; addPathSegments: #('api' '1' 'origin' 'git' 'url' 'https:' '' 'github.com' 'hylang' 'hy'); yourself. > > You can use this as follows. > > ZnUrl new scheme: #https; host: 'archive.softwareheritage.org'; addPathSegments: #('api' '1' 'origin' 'git' 'url' 'https:' '' 'github.com' 'hylang' 'hy'); retrieveContents. > > ZnEasy get: (ZnUrl new scheme: #https; host: 'archive.softwareheritage.org'; addPathSegments: #('api' '1' 'origin' 'git' 'url' 'https:' '' 'github.com' 'hylang' 'hy'); yourself). > > Regards, > > Sven > |
Free forum by Nabble | Edit this page |