Report

Slightly off topic, but I know some here will be interested... planning has been submitted to remove RAAC and instal new roof on the O2 Academy. I guess we still might be a year away, but it is progress.

Three intimate shows - sans Jimi - announced today. Stoke, Birkenhead and Hebden Bridge I think.

Great post! A bit of info about the queue-it side - (caveats - all the following is from having a look at their github repos and using dev tools on see tickets)   queue-it have a nice diagram showing how the queue-it Edge connector (EC) (term for the bit of queue-it code that runs in Akamai) interacts with the origin server (seetickets) and queue-it  https://github.com/queueit/Documentation/tree/main/edge-connectors   The diagram/process could be well out of date (2 years old) but from a look at the Sam Fender (SF) tix on seetickets some parts of that described flow are in place (hard to say if all of it is the same since there is no actual queueing for SF at the moment)   So using the SF use case to (partially) step thru the EC diagram  - hit link https://www.seetickets.com/event/sam-fender/first-direct-arena/3205111 with your browser. This is a protected url and will be processed by Akamai first - The EC in Akamai sees you have no QueueITAccepted cookie so it redirects you to https://www.seetickets.com/queue/ with an enqueue token as a query string param - Since there is no queuing at the moment for SF you're redirected to https://www.seetickets.com/event/sam-fender/first-direct-arena/3205111?queueittoken=XXXXX by the EC. You now have a  queueittoken token (I think this would be generated by queue-it in a waiting room case but in this case it is generated by the EC) - the EC validates the queueittoken and in the response headers sets a QueueITAccepted cookie (not token) for the session - that QueueITAccepted cookie is now present for all subsequent requests, it is checked by the EC and if valid the EC allows the request back to the origin (seetickets)   [speculation as to how this will work for Glasto sales] - I think this enqueue token will be given to Glasto users when they gather for the prequeue i.e. the page with the countdown timer before sales start - the enqueue token will be part of the redirect to the queue-it waiting room - users who go to glasto sales url after sale has started will be given a enqueue token that puts them at the back of the queue (there are docs in queue-it.com showing how you can prioritise one set of users - namely those who gather at the prequeue countdown page over the latecomers who now have a standard first-in first-out queuing experience - but behind all those who gathered at the prequeue countdown page) - queue-it waiting room redirects users as their turn comes back to the EC with a queueittoken token - the EC validates the queueittoken, one of the checks can be an ip check (the token can have an ip encoded in it, the EC checks if it corresponds to the source ip of the request https://github.com/queueit/KnownUser.V3.Akamai/blob/master/sdk/queueit-knownuserv3-sdk.js#L1072 ). I am not saying this happens all the time, the code will handle situations where the ip is not in the token). - if queueittoken is valid your browser is given a QueueITAccepted cookie by the EC and allows you thru to the origin (seetickets) where you can happily buy tickets. As you browse thru the ticket buying flow the presence (or not) of QueueITAccepted cookie is checked and validated by the EC on each request. It has an expiry time and once that is reached the EC will redirect you back to the waiting room [end speculation]   So 2 tokens and a cookie, all tamper proof (encrypted or signed). The can contain fields like expiry, ip (or a hash of it), queueid. They are all validated on each redirect. - enqueuetoken is for entering the waiting room to queue. It can have a uuid - which might be the basis for the your position in the queue https://github.com/queueit/KnownUser.V3.Akamai/blob/master/sdk/queueToken.js#L405  - queueittoken, you get after you have finished queueing - I think it can be generated by the queueing room but in the SF case it was generated by the EC https://github.com/queueit/KnownUser.V3.Akamai/blob/master/sdk/queueit-knownuserv3-sdk.js#L780 - QueueITAccepted - the cookie that let's you thru! https://github.com/queueit/KnownUser.V3.Akamai/blob/master/sdk/queueit-knownuserv3-sdk.js#L1140 Here is the validation done by the EC on QueueITAccepted  https://github.com/queueit/KnownUser.V3.Akamai/blob/master/sdk/queueit-knownuserv3-sdk.js#L1211 (which can include an ip check)   In the Sam Fender case the queueittoken and QueueITAccepted cookie I got did not have an ip or hashed ip (they are signed rather than encrypted so you can inspect the fields). Am sure that is all configurable by seetickets/queue-it depending on the event.   I don't think queue-it are doing much checking (bot detection, browser fingerprinting, browser reputation, user behaviour) in their EC code other than ip checking - and this check is just to confirm the token/cookie wasn't created on source ip A and then copied to be used on source ip B. Queue-it may well be are doing the more sophisticated detection in their waiting room/queuing component - which is place for bots to attack, to try and jump ahead of the queue. For the EC code they are leaving all that to Akamai (who've been doing it for years).    Lastly - some of queue-it variables for the EC are handily listed https://github.com/queueit/KnownUser.V3.Akamai/tree/master  It sort of confirms some of the above e.g. "If enabled at waitingroom, it is used to validate the vistor IP by connector" final thoughts - I think Akamai will be the source of "403 Forbidden" etc. Check your devices https://www.akamai.com/us/en/clientrep-lookup/ - we don't know how your queue position is formed other than "random" - there is a flexible "payload" field on the enqueuetoken which could be used to transmit info from Akamai to queue-it (e.g. browser behaviour/reputation) which might be used to determine where you are in the queue but it doesn't seem to be used for that from a look at the code on that repo (which is 2 years old of course!) - one interesting blog post from queue-it about how tickets can appear to be sold out when they are not - not sure if this will apply to Glasto since the tickets are only removed from inventory when the card transaction goes thru (??) but it should still encourage us to not give up https://queue-it.com/blog/tickets-sold-out-debunking-instant-sellout-myth/ - queue-it queues can be paused as well. e.g. if seetickets have some of DB meltdown then they can pause the queue (no more users come thru to seetickets), sort things out and unpause.   

Maybe not last minute but once the Dave stuff came up maybe some Live Nation things were moved around ie LP from Download to R&L unless of course they do get announced for BST. Then that’ll mean Foos for R&L or if they’ve dropped and LP at BST then a different set to what we’re currently expecting completely. Maybe something like below if we don’t get Linkin Park or Foos?    Post Malone - Kasabian   Chase & Status - BMTH   Chappell Roan - Central Cee   Special Guest Hozier

It's amazing how many people probably never listened to those songs when they came out but as you say they are now well known and loved songs. Throw in Mis-shapes & Sorted for E's & Wizz and you have half a set that everyone will know.   As some one who does not go to Glastonbury and only watches on TV, I can't believe that some do not think they are headline worthy and don't have the tunes. As a TV Glastonbury fan, I can say that lots of TV viewers will know more Pulp songs then many of the headliners Glastonbury has had.