- Pharo-users - lists.pharo.org

Re: [Pharo-users] ZnClient receiving Expires header with Max-Age instead of HTTP formatted DateAndTime

by Paul DeBruicker

Seems like the invalid date could be anything and the spec gives '0' as the example invalid date. I'm not using #expiresTimeStamp or #parseHttpDate: explicitly its just that the GET request was failing on that date parsing error, when checking if the Cookie was expired. I think your proposed ZnCookie>>#isExpired is the right way to go e.g. isExpired | expirationTimeStamp | (self hasAttribute: 'expire') ifFalse: [ ^ false ]. [ expirationTimeStamp := self expiresTimeStamp ] on: Error do: [ ^ false ]. "note that max-age (#maxage) is not used" ^ expirationTimeStamp asUTC < DateAndTime now asUTC Sven Van Caekenberghe-2 wrote > Hi Paul, > >> On 11 Sep 2018, at 06:02, PAUL DEBRUICKER < > pdebruic@ > > wrote: >> >> Hi Sven - >> >> This is in Pharo 6.1. >> >> There is an API I'm using which sometimes returns a string only >> containing a single instance of the number 0 in the "Expires" field, so >> the #expiresTimeStamp method sends that to #parseHttpDate: and since it >> can't be parsed into a date an error is thrown. Seems like Zinc should >> be able to handle that based on the spec here: >> https://tools.ietf.org/html/rfc7234#section-5.3 >> >> >> Would you rather I changed the implementation of parseHttpDate: to add an >> empty check on the parsed tokens e.g. > > IIRC some months ago, there were some changes to this area, but I forgot > the details and the before state. > > Anyway, reading RFC7234's section that you reference, maybe we do need to > make another change, but I am not sure. > > Let's start by explaining what there is today and why it is like that: > #parseHttpDate: and #expiresTimestamp do indeed throw exceptions (by > design), while #isExpired is the more high level access method. > > Consider: > > (ZnCookie name: 'foo' value: '100') isExpired. > > => false > > ZnUtils parseHttpDate: '0'. > > => Boom > > (ZnCookie name: 'foo' value: '100') expires: '0'; expiresTimeStamp. > > => Boom > > (ZnCookie name: 'foo' value: '100') expires: '0'; isExpired. > > => false > > Could you use #isExpired and does it do what you want/expect ? > > Reading the spec again, I am not 100% sure about the error case (existing > but zero or wrong Expires header), maybe that should be true instead of > false. > > isExpired > | expirationTimeStamp | > (self hasAttribute: 'expire') ifFalse: [ ^ false ]. > [ expirationTimeStamp := self expiresTimeStamp ] on: Error do: [ ^ false > ]. > "note that max-age (#maxage) is not used" > ^ expirationTimeStamp asUTC < DateAndTime now asUTC > > What do you think ? > Anyone else with an opinion ? > > Sven > >> parseHttpDate: string >> "self parseHttpDate: 'Tue, 13 Sep 2011 08:04:49 GMT'." >> "self parseHttpDate: 'Tue, 13-Sep-2011 08:04:51 GMT'." >> "self parseHttpDate: 'Tue Jan 01 00:00:01 2036 GMT'." >> >> | tokens day month year hour minute second months map yearToken | >> string size = 1 ifTrue:[ ^DateAndTime epoch ]. >> tokens := (string findTokens: #( $ $- $: $, )) allButFirst. >> >> ... >> >> >> Or add a string size guard check in #expiresTimeStamp ? e.g. >> >> expiresTimeStamp >> self expires >> ifNil: [ ^ DateAndTime now + 1 day ] >> ifNotNil: [ :exp | >> exp size = 1 >> ifTrue: [ ^ DateAndTime epoch ]. >> ^ ZnUtils parseHttpDate: exp ] >> >> >> Thanks >> >> Paul -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 11, 2018

Re: [Pharo-users] ZnClient receiving Expires header with Max-Age instead of HTTP formatted DateAndTime

by Sven Van Caekenberghe

Yes, that is how I read it now too. > On 11 Sep 2018, at 14:55, Erik Stel <erik.stel(a)gmail.com> wrote: > > Sven, > > According to the spec "0" or invalid date formats should mean 'isExpired' > (as you already suggested): > A cache recipient MUST interpret invalid date formats, especially the > value "0", as representing a time in the past (i.e., "already > expired"). > > So I would vote for having 'isExpired' answer 'true' in those cases. Having > 'expiresTimeStamp' throw an error seems reasonable. The sender can catch the > exception. > > Cheers, > Erik > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >

Sept. 11, 2018

Re: [Pharo-users] ZnClient receiving Expires header with Max-Age instead of HTTP formatted DateAndTime

by Sven Van Caekenberghe

> On 11 Sep 2018, at 13:53, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi Paul, > >> On 11 Sep 2018, at 06:02, PAUL DEBRUICKER <pdebruic(a)gmail.com> wrote: >> >> Hi Sven - >> >> This is in Pharo 6.1. >> >> There is an API I'm using which sometimes returns a string only containing a single instance of the number 0 in the "Expires" field, so the #expiresTimeStamp method sends that to #parseHttpDate: and since it can't be parsed into a date an error is thrown. Seems like Zinc should be able to handle that based on the spec here: https://tools.ietf.org/html/rfc7234#section-5.3 >> >> >> Would you rather I changed the implementation of parseHttpDate: to add an empty check on the parsed tokens e.g. > > IIRC some months ago, there were some changes to this area, but I forgot the details and the before state. > > Anyway, reading RFC7234's section that you reference, maybe we do need to make another change, but I am not sure. > > Let's start by explaining what there is today and why it is like that: #parseHttpDate: and #expiresTimestamp do indeed throw exceptions (by design), while #isExpired is the more high level access method. > > Consider: > > (ZnCookie name: 'foo' value: '100') isExpired. > > => false > > ZnUtils parseHttpDate: '0'. > > => Boom > > (ZnCookie name: 'foo' value: '100') expires: '0'; expiresTimeStamp. > > => Boom > > (ZnCookie name: 'foo' value: '100') expires: '0'; isExpired. > > => false > > Could you use #isExpired and does it do what you want/expect ? > > Reading the spec again, I am not 100% sure about the error case (existing but zero or wrong Expires header), maybe that should be true instead of false. > > isExpired > | expirationTimeStamp | > (self hasAttribute: 'expire') ifFalse: [ ^ false ]. > [ expirationTimeStamp := self expiresTimeStamp ] on: Error do: [ ^ false ]. > "note that max-age (#maxage) is not used" > ^ expirationTimeStamp asUTC < DateAndTime now asUTC > > What do you think ? > Anyone else with an opinion ? I just noticed that we are mixing request/response http headers with cookies, which might not be a good idea. > Sven > >> parseHttpDate: string >> "self parseHttpDate: 'Tue, 13 Sep 2011 08:04:49 GMT'." >> "self parseHttpDate: 'Tue, 13-Sep-2011 08:04:51 GMT'." >> "self parseHttpDate: 'Tue Jan 01 00:00:01 2036 GMT'." >> >> | tokens day month year hour minute second months map yearToken | >> string size = 1 ifTrue:[ ^DateAndTime epoch ]. >> tokens := (string findTokens: #( $ $- $: $, )) allButFirst. >> >> ... >> >> >> Or add a string size guard check in #expiresTimeStamp ? e.g. >> >> expiresTimeStamp >> self expires >> ifNil: [ ^ DateAndTime now + 1 day ] >> ifNotNil: [ :exp | >> exp size = 1 >> ifTrue: [ ^ DateAndTime epoch ]. >> ^ ZnUtils parseHttpDate: exp ] >> >> >> Thanks >> >> Paul

Sept. 11, 2018

Re: [Pharo-users] ZnClient receiving Expires header with Max-Age instead of HTTP formatted DateAndTime

by Erik Stel

Sven, According to the spec "0" or invalid date formats should mean 'isExpired' (as you already suggested): A cache recipient MUST interpret invalid date formats, especially the value "0", as representing a time in the past (i.e., "already expired"). So I would vote for having 'isExpired' answer 'true' in those cases. Having 'expiresTimeStamp' throw an error seems reasonable. The sender can catch the exception. Cheers, Erik -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 11, 2018

Re: [Pharo-users] ZnURL and parsing URL with diacritics

by Erik Stel

Check out the following info: https://en.wikipedia.org/wiki/Internationalized_Resource_Identifier <https://en.wikipedia.org/wiki/Internationalized_Resource_Identifier> The REST API might be answering an IRI instead of an URI in which case it might not be faulty after all (I did not check the API myself). -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Sept. 11, 2018

Re: [Pharo-users] ZnClient receiving Expires header with Max-Age instead of HTTP formatted DateAndTime

by Sven Van Caekenberghe

Hi Paul, > On 11 Sep 2018, at 06:02, PAUL DEBRUICKER <pdebruic(a)gmail.com> wrote: > > Hi Sven - > > This is in Pharo 6.1. > > There is an API I'm using which sometimes returns a string only containing a single instance of the number 0 in the "Expires" field, so the #expiresTimeStamp method sends that to #parseHttpDate: and since it can't be parsed into a date an error is thrown. Seems like Zinc should be able to handle that based on the spec here: https://tools.ietf.org/html/rfc7234#section-5.3 > > > Would you rather I changed the implementation of parseHttpDate: to add an empty check on the parsed tokens e.g. IIRC some months ago, there were some changes to this area, but I forgot the details and the before state. Anyway, reading RFC7234's section that you reference, maybe we do need to make another change, but I am not sure. Let's start by explaining what there is today and why it is like that: #parseHttpDate: and #expiresTimestamp do indeed throw exceptions (by design), while #isExpired is the more high level access method. Consider: (ZnCookie name: 'foo' value: '100') isExpired. => false ZnUtils parseHttpDate: '0'. => Boom (ZnCookie name: 'foo' value: '100') expires: '0'; expiresTimeStamp. => Boom (ZnCookie name: 'foo' value: '100') expires: '0'; isExpired. => false Could you use #isExpired and does it do what you want/expect ? Reading the spec again, I am not 100% sure about the error case (existing but zero or wrong Expires header), maybe that should be true instead of false. isExpired | expirationTimeStamp | (self hasAttribute: 'expire') ifFalse: [ ^ false ]. [ expirationTimeStamp := self expiresTimeStamp ] on: Error do: [ ^ false ]. "note that max-age (#maxage) is not used" ^ expirationTimeStamp asUTC < DateAndTime now asUTC What do you think ? Anyone else with an opinion ? Sven > parseHttpDate: string > "self parseHttpDate: 'Tue, 13 Sep 2011 08:04:49 GMT'." > "self parseHttpDate: 'Tue, 13-Sep-2011 08:04:51 GMT'." > "self parseHttpDate: 'Tue Jan 01 00:00:01 2036 GMT'." > > | tokens day month year hour minute second months map yearToken | > string size = 1 ifTrue:[ ^DateAndTime epoch ]. > tokens := (string findTokens: #( $ $- $: $, )) allButFirst. > > ... > > > Or add a string size guard check in #expiresTimeStamp ? e.g. > > expiresTimeStamp > self expires > ifNil: [ ^ DateAndTime now + 1 day ] > ifNotNil: [ :exp | > exp size = 1 > ifTrue: [ ^ DateAndTime epoch ]. > ^ ZnUtils parseHttpDate: exp ] > > > Thanks > > Paul

Sept. 11, 2018

ZnClient receiving Expires header with Max-Age instead of HTTP formatted DateAndTime

by PAUL DEBRUICKER

Hi Sven - This is in Pharo 6.1. There is an API I'm using which sometimes returns a string only containing a single instance of the number 0 in the "Expires" field, so the #expiresTimeStamp method sends that to #parseHttpDate: and since it can't be parsed into a date an error is thrown. Seems like Zinc should be able to handle that based on the spec here: https://tools.ietf.org/html/rfc7234#section-5.3 Would you rather I changed the implementation of parseHttpDate: to add an empty check on the parsed tokens e.g. parseHttpDate: string "self parseHttpDate: 'Tue, 13 Sep 2011 08:04:49 GMT'." "self parseHttpDate: 'Tue, 13-Sep-2011 08:04:51 GMT'." "self parseHttpDate: 'Tue Jan 01 00:00:01 2036 GMT'." | tokens day month year hour minute second months map yearToken | string size = 1 ifTrue:[ ^DateAndTime epoch ]. tokens := (string findTokens: #( $ $- $: $, )) allButFirst. ... Or add a string size guard check in #expiresTimeStamp ? e.g. expiresTimeStamp self expires ifNil: [ ^ DateAndTime now + 1 day ] ifNotNil: [ :exp | exp size = 1 ifTrue: [ ^ DateAndTime epoch ]. ^ ZnUtils parseHttpDate: exp ] Thanks Paul

Sept. 11, 2018

Re: [Pharo-users] Query on Pharo syntax

by Ben Coman

Its a very interesting and elegant aspect of Pharo and I'm sure there are others at different parts of their journey learning Pharo who learnt something new from your question. cheers -ben On Tue, 11 Sep 2018 at 03:13, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > Thanks Ben â itâs all clear now. Thanks also to Esteban, who spared my > blushes by answering direct! > > Peter Kenny > > > > *From:* Pharo-users <pharo-users-bounces(a)lists.pharo.org> *On Behalf Of *Ben > Coman > *Sent:* 10 September 2018 19:56 > *To:* Any question about pharo is welcome <pharo-users(a)lists.pharo.org> > *Subject:* Re: [Pharo-users] Query on Pharo syntax > > > > > > On Tue, 11 Sep 2018 at 02:44, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > Hi All > > > > This is an idiot question, I should know the answer, but I have looked > around and canât find relevant documentation. Iâm not asking for a full > answer, just a pointer as to where to start looking. > > > > I have seen from examples in this forum that an expression like the > following: > > > > paras collect: [para| para prettyPrinted] > > > > can be written more concisely as: > > > > paras collect: #prettyPrinted > > > > which obviously works when I try it. It doesnât seem to fit in with the > definition of #collect:, which requires a block as argument. Where can I > find the relevant definition, either in method comments or in some general > manual? Can the notation be extended, > > > > Its not special notation. Just a normal object (a Symbol) passed via a > normal message. > > > > for example to #select: - obviously with an argument which returns a > Boolean? Can it be used with a method which requires an argument, e.g. as > myArray collect: (#myMethod: arg)? Are there any other extensions? > > > > Any help gratefully received. > > > > Peter Kenny > > > > Full answer ;) > > Its a combination of the following two methods... > > > > Collection >> collect: aBlock > > | newCollection | > > newCollection := self species new. > > self do: [:each | newCollection add: (aBlock value: each)]. > > ^ newCollection > > > > Symbol value: anObject > > ^anObject perform: self. > > > > When /aBlock/ is a symbol, that symbol is performed on /each/ element. > > And looking at #select: , yes it works the same... > > > > Collection >> select: aBlock > > | newCollection | > > newCollection := self copyEmpty. > > self do: [ :each | > > (aBlock value: each) > > ifTrue: [ newCollection add: > each ]]. > > ^newCollection > > > > cheers -ben >

Sept. 11, 2018

Re: [Pharo-users] Query on Pharo syntax

by PBKResearch

Thanks Ben â itâs all clear now. Thanks also to Esteban, who spared my blushes by answering direct! Peter Kenny From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Ben Coman Sent: 10 September 2018 19:56 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] Query on Pharo syntax On Tue, 11 Sep 2018 at 02:44, PBKResearch <peter(a)pbkresearch.co.uk <mailto:peter@pbkresearch.co.uk> > wrote: Hi All This is an idiot question, I should know the answer, but I have looked around and canât find relevant documentation. Iâm not asking for a full answer, just a pointer as to where to start looking. I have seen from examples in this forum that an expression like the following: paras collect: [para| para prettyPrinted] can be written more concisely as: paras collect: #prettyPrinted which obviously works when I try it. It doesnât seem to fit in with the definition of #collect:, which requires a block as argument. Where can I find the relevant definition, either in method comments or in some general manual? Can the notation be extended, Its not special notation. Just a normal object (a Symbol) passed via a normal message. for example to #select: - obviously with an argument which returns a Boolean? Can it be used with a method which requires an argument, e.g. as myArray collect: (#myMethod: arg)? Are there any other extensions? Any help gratefully received. Peter Kenny Full answer ;) Its a combination of the following two methods... Collection >> collect: aBlock | newCollection | newCollection := self species new. self do: [:each | newCollection add: (aBlock value: each)]. ^ newCollection Symbol value: anObject ^anObject perform: self. When /aBlock/ is a symbol, that symbol is performed on /each/ element. And looking at #select: , yes it works the same... Collection >> select: aBlock | newCollection | newCollection := self copyEmpty. self do: [ :each | (aBlock value: each) ifTrue: [ newCollection add: each ]]. ^newCollection cheers -ben

Sept. 10, 2018

Re: [Pharo-users] legitimate values for ZnClient>>accept:

by Ben Coman

On Tue, 11 Sep 2018 at 02:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Ben, > > > On 10 Sep 2018, at 20:36, Ben Coman <btc(a)openinworld.com> wrote: > > > > Hi Sven, > > > > I had a sample http request specified to have ```Accept-Encoding: gzip``` > > and too a guess the following would work... ```client := ZnClient new > accept: 'gzip' ``` > > but it doesn't since ZnClient>>accept: > > effectively does ``` 'gzip' asZnMimeType ``` > > which expects the string to contain a forward-slash > > > > However this page seems to indicate no slash is required... > > > https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Encoding > > > > If I call ```client request setAccept: 'gzip' ``` > > I am able to match what is expected (checked with WireShark) > > but I'm not sure the sample I was provided is legit or I'm doing > something wrong > > > > cheers -ben > > You seem to be confusing two different headers, Indeed. I plead domestic blindness. > Accept and Accept-Encoding (there are many more: > https://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Request_fields) > > #accept: does indeed take a mime-type as argument, as it should. > > I think you are looking for #setAcceptEncodingGzip > Yes, thx. cheers -ben

Sept. 10, 2018