- From: Robin MARX <robin.marx@uhasselt.be>
- Date: Thu, 11 Jul 2019 12:15:16 +0200
- To: Kazuho Oku <kazuhooku@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAC7UV9Zc0Urfz+beqFtMSeuy=F4NbqA8Ym=V-5n4PhvexPa-dw@mail.gmail.com>
Hello Kazuho, Yes, you are right, my apologies. Patrick's proposal recently changed to the approach proposed by Ian Swett in https://github.com/quicwg/base-drafts/pull/2700 and I was still thinking of the old version. I see that you have a PR that splits urgency up into about 8 numerical levels (https://github.com/kazuho/draft-kazuho-httpbis-priority/pull/34), each with their own semantics and logic. This feels a bit like SPDY priorities-on-steroids and is indeed a nice middle ground between Patrick's 64 levels and your original 3. I still don't like the naming of the groups, but to settle that I guess we will need to resort to a duel at dawn ;) I've left some notes on the PR adding some additional examples to the text to further clarify intended usage. With something like that in, I feel it's a workable proposal. With best regards, Robin On Thu, 11 Jul 2019 at 05:46, Kazuho Oku <kazuhooku@gmail.com> wrote: > > > 2019年7月10日(水) 18:19 Robin MARX <robin.marx@uhasselt.be>: > >> Hello Kazuho, >> >> I agree that more extensive signaling would be research project with a >> medium/high turn around time. >> I think that there might have been a mis-interpretation from my end on >> that count though: I interpreted this draft as a way to be able to postpone >> the prioritization to after H3 / not make finishing H3 dependent on it. >> My assumption was that we would ship H3 with the draft-21 changes (aka: >> very similar to H2's setup) and then augment/extend that with this approach >> e.g., 6 months afterwards. >> >> Instead, if I understand you correctly, it is the intent to finish this >> together with H3 and expect browsers/clients to implement this together >> with H3 as its default (and only?) standardized prioritization option. >> > > Yes. That is the intent. > > My view is that if we are to have something other than the H2-based > design, it's beneficial to do it before or as the H3 hits the market. This > is because then we could use H3 as the vehicle for providing something > better, at the same time easing the pain of people implementing the complex > H2-based scheme. > > >> As such, it is my fear that we would be trying to rush this, to have >> "something" ready by the deadline, without properly testing or >> "researching" how it would work or if it covers all use cases. Afaict, >> that's going dangerously close to how we got the H2 setup in the first >> place... >> If it's the intent to have something simpler for H3 that allows for >> rudimentary tie-ins for server-side prioritization and that works well with >> existing browser setups, I feel Patrick Meenan's original proposal is far >> superior and more flexible than the current proposal in the draft for this >> purpose, while being nearly as simple/straightforward. >> To be clear: we could still use the "HTTP header" approach, just not the >> "urgency" and "progressive" aspects then (e.g., priority= level=63, >> concurrency=3). >> > > I think that there is a slight misunderstanding here. > > Assuming that the Patrick's proposal your are referring to is > https://github.com/pmeenan/http3-prioritization-proposal, concurrency is > a boolean parameter. In terms of functionality, it is identical to the > "progressive" parameter of the Priority header proposal. > > Therefore, the only difference between the two proposals regarding how the > priorities are expressed are: > * if each urgency has a meaning > * the number of the urgency levels (3 vs. 64) > > That said, I can see that just having 3 levels would be too restrictive > for browsers. > > If we are to propose the header-based approach as "the" priority scheme > for H3, I think we should try to provide a way to transplant the urgency > levels (that are currently internal to the browsers) to the "urgency" > parameter. > > >> Later work after the "research project" is done could then add additional >> header values to allow more use cases / semantics etc. >> >> With best regards, >> Robin >> >> >> >> >> >> >> >> On Wed, 10 Jul 2019 at 03:25, Kazuho Oku <kazuhooku@gmail.com> wrote: >> >>> Hi Robin, >>> >>> 2019年7月9日(火) 22:56 Robin MARX <robin.marx@uhasselt.be>: >>> >>>> Hello Kazuho, >>>> >>>> Thanks for the comments, most of which I agree with. The clarification >>>> from Lucas elsewhere that the frame could contain an "opaque encoded >>>> header" makes things a bit more pleasant for me. >>>> I have created some issues on github to further explain some of my >>>> points, as I feel some of your comments don't really answer my other >>>> reservations. >>>> >>>> 5) and 7) On the semantics of the used header names and values: >>>> https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/27 >>>> My point was more general that the semantics of what you have now >>>> do not map (perfectly) to the semantics that are already in-place when >>>> talking about browser resource loading and this can create confusion down >>>> the road. >>>> Simply clarifying what your "re-defined" blocking means does not >>>> help prevent confusion all that much imo. >>>> With your examples at the end as well, for me you are "abusing" the >>>> blocking indicator to manipulate sending behaviour, rather than >>>> communicating the actual semantics of a blocking resource (a CSS in the >>>> document is still render blocking, even if it is less important than one in >>>> the <head>). >>>> >>> >>> By saying "communicating the actual semantics of a blocking resource", I >>> assume that you are suggesting to send something like "this is a request >>> initiated by a style tag in body." Generally speaking, I think signaling >>> that sort of signal is a good idea. >>> >>> OTOH, that's going to be a research project. I am open to defining such >>> signals alongside "urgency" that's being proposed by the document. OTOH, >>> "switching" to that approach would mean that it'd be less likely that we'd >>> have an alternative prioritization scheme adopted when we ship H3. >>> >>> Therefore, it is my view that what we should do now is encode the >>> priority levels that the browsers use today, at the same time assigning >>> meanings to each of the priority levels. >>> >>> We need to assign meanings so that servers can tweak the prioritization >>> scheme, because the server needs to know what type of resource is assigned >>> to each level. >>> >>> Consider the case where a server wants to send HTML before CSS (it's not >>> a terrible idea, that's what Chrome suggests using the H2 scheme now). >>> That'd be only possible when the client uses a signal like "document", >>> "blocking". If the signals were named like "highest" or "medium" (or "5" or >>> "4"), and without the knowledge of to which of the two HTML and CSS will be >>> associated to, it would be impossible for a server to prioritize HTML above >>> CSS (or in the opposite order). >>> >>> >>>> Resolution to this can be as simple as re-naming the values to >>>> prevent confusion. >>>> >>> >>> We can discuss about the names. >>> >>> >>>> 6) On the array of use cases / semantics that can be represented/should >>>> be representable: >>>> https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/28 >>>> You say for example that promoting an image to a hero image is not >>>> the intent of the example. I can then ask: how would you indicate a >>>> hero-image server to client then? There doesn't seem to be a way in the >>>> current setup to (properly) do this. >>>> >>> >>> You can set the urgency. For example, if the server believes that an >>> image is as important as the document itself in terms of "using" the >>> document, it can set the value of the response header to "Priority: >>> urgency=document." That would be the instruction to the H2/H3 terminator >>> that the response should be given the same priority level as the HTML. >>> >>> >>>> You could say that the server simply uses its internal knowledge >>>> and sends that image first, but then the whole "this is usable by >>>> intermediates"-argument becomes less powerful. >>>> I feel we should communicate as much metadata as possible back to >>>> the server to allow it to make complex decisions, if it so chooses. The >>>> server can still ignore most of the metadata if it decides to implement a >>>> simpler scheme. >>>> In essence, the metadata communicated in the header should, imo, be >>>> relatively de-coupled from the concrete implementations at the server (and >>>> the current HTTP/2 setups) >>>> >>>> With best regards, >>>> Robin >>>> >>>> >>>> >>>> On Tue, 9 Jul 2019 at 03:42, Kazuho Oku <kazuhooku@gmail.com> wrote: >>>> >>>>> Hi Robin, >>>>> >>>>> Thank you for the comments. My responses below. >>>>> >>>>> 2019年7月8日(月) 23:56 Robin MARX <robin.marx@uhasselt.be>: >>>>> >>>>>> Hello Kazuho and Lucas, >>>>>> >>>>>> Thank you for the draft. Most of this feedback I've given elsewhere >>>>>> as well, but to keep everything in one place: >>>>>> >>>>>> 1) I really like the header-based approach. It's extensible, allows >>>>>> us to make progress on H3, is easier to use/understand, >>>>>> can be "backported" to H2, has other nice properties which you touch >>>>>> upon in the text (intermediates, caching, etc.) >>>>>> >>>>> >>>>> I'm delighted to hear that. >>>>> >>>>> >>>>>> 2) I really dislike the header-based approach. It makes >>>>>> re-prioritization a mess. You don't touch upon this (yet) in the draft, >>>>>> but the discussion on github ( >>>>>> https://github.com/kazuho/draft-kazuho-httpbis-priority/wiki/Roughing-out-reprioritization) >>>>>> proposes >>>>>> using a separate, special H3/H2 level frame to provide this. This >>>>>> just feels -very- dirty to me. The problem is that I can't really think >>>>>> of a (much) better solution, other than referring to re-prioritized >>>>>> resource A in resource B's headers, which is a whole other can of worms. >>>>>> I'm not >>>>>> really opposed to using the separate frame if that's the only option, >>>>>> but it still takes away some of the nice properties of 1) >>>>>> >>>>> >>>>> While I can see how you feel sad, I am not worried, because >>>>> reprioritization can also be HTTP-version-independent in terms of API. The >>>>> only difference would be how the prioritization hints (in text) are encoded >>>>> as frames. >>>>> >>>>> >>>>>> 3) I really like the switch to "absolute"/"stateless" priority >>>>>> levels/semantics (as you're referred to them elsewhere), as opposed to >>>>>> building the tree directly. >>>>>> This really helps for (partial) server-side (re-)prioritization. It >>>>>> does require the server (implementers) to know a bit more about how >>>>>> browsers work, but >>>>>> I don't really see that as a big issue (given that we provide >>>>>> guidance and examples on proper options) >>>>>> >>>>> >>>>> :+1: >>>>> >>>>> >>>>>> >>>>>> 4) I don't feel the current defined priority fields+values cover the >>>>>> use cases though. You touch upon this in section 5.2, but I disagree with >>>>>> you there: >>>>>> For me, these new priority primitives are the core of the proposal >>>>>> (not the header-based approach. I would champion these new semantics in a >>>>>> frame-based setup as well) >>>>>> and imo these should be nailed down (semi-)completely before >>>>>> considering this approach. There should probably be more degrees of >>>>>> "urgency" \ >>>>>> (e.g., as Patrick Meenan mentioned things like "deferred" and >>>>>> "background'), and there should maybe be something like >>>>>> "importance"/"weight"/"precedence"/... >>>>>> to be more fine-grained within resources of the same "urgency" level. >>>>>> >>>>> >>>>> I think that adding "deferred" is easy, assuming that we would agree >>>>> on the meaning. It would mean the responses that should be sent _after_ the >>>>> "non-blocking" responses. >>>>> >>>>> Re "background," I think we need to discuss how we want to prioritize >>>>> them. Should we assign it a yet lower precedence (than "deferred")? Or >>>>> should we state that it should be given some amount of bandwidth regardless >>>>> of other responses? >>>>> >>>>> As mentioned in >>>>>> https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/12, >>>>>> it might be good >>>>>> to look at the existing work on the Priority Hints spec, seeing as >>>>>> they probably have already looked at much of this as well. >>>>>> >>>>>> 5) I am also not sure about the interpretation of the current fields. >>>>>> For example, as noted by Patrick ( >>>>>> https://github.com/kazuho/draft-kazuho-httpbis-priority/issues/13), >>>>>> blocking has a specific meaning and it doesn't map 100% to your >>>>>> current text. >>>>>> >>>>> >>>>> I assume this to have been fixed by >>>>> https://github.com/kazuho/draft-kazuho-httpbis-priority/pull/14. >>>>> IIUC, Patrick's concern was that "blocks the processing of the document" >>>>> seems to be applicable to JavaScript files loaded in <BODY>. In #14 we've >>>>> changed the text to "blocks using the document", and I think it's clearer >>>>> that urgency=blocking does not necessarily apply to such JavaScript files. >>>>> >>>>> >>>>>> Similarly, what does progressive mean exactly? IIUC JS and CSS can be >>>>>> parsed/compiled >>>>>> in a streaming fashion in modern engines as well, it's mainly their >>>>>> application that is delayed until they are fully available. >>>>>> >>>>> >>>>> When used by a client, it is a signal that indicates if the client >>>>> prefers receiving the responses with the bandwidth being distributed among >>>>> similar responses, or if it prefers receiving the response one by one. >>>>> >>>>> Similarly, is a non-progressively encoded jpeg >>>>>> counted as "progressive"? How does the browser know if a JPEG will be >>>>>> progressive or not when making the request? I feel you've got the answers, >>>>>> but the usage of these >>>>>> specific terms can make it more difficult to actually use this scheme >>>>>> in practice. >>>>>> >>>>> >>>>> For images, a browser should set progressive to 1, when it can assume >>>>> that the image can be rendered progressively, as doing so improves user >>>>> experience. >>>>> >>>>> Servers would benefit from setting progressive to 0 for baseline JPEG >>>>> images, assuming that sending the first few percent of the file does not >>>>> improve user experience. >>>>> >>>>> Assuming that what I've stated here makes sense, I think it might be a >>>>> good idea to clarify these points using examples in the draft. >>>>> >>>>> >>>>>> >>>>>> 6) This is also clear a bit from the example in section 3 (switching >>>>>> image from progressive to non-progressive). I -assume- the goal here is to >>>>>> do something like a "hero" image, >>>>>> which you want to send before other images. However, it feels to me >>>>>> that "abusing" the progressive field for this is not the best way to go >>>>>> about that. >>>>>> >>>>> >>>>> As stated above, that's not the intent. >>>>> >>>>> >>>>>> >>>>>> 7) Most of this comes together in the fact that I'm having a hard >>>>>> time thinking of how to represent existing H2 logic/browser use cases in >>>>>> this new scheme. >>>>>> E.g., how would you derive Chrome's current "dynamic fifo" from this >>>>>> metadata? How would you implement Patrick Meenan's proposed 'ideal' setup >>>>>> from these directives? >>>>>> Having a couple of concrete examples would help to understand your >>>>>> intents and probably also to ferret out some missing pieces. >>>>>> >>>>> >>>>> I agree that talking about mappings is a good idea. I think it would >>>>> be something like: >>>>> >>>>> HTML -> urgency=document, progressive=?1 >>>>> JS, CSS in HEAD -> urgency=blocking, progressive=?0 >>>>> images -> urgency=non-blocking, progressive=?1 >>>>> async-loaded JS -> urgency=deferred, progressive=?0 >>>>> >>>>> There's some wiggle room for fonts and JS, CSS being used inside BODY. >>>>> Depending on how important they seem to be, a client can set urgency to >>>>> "blocking" (if it essentially prevents the document from being used), to >>>>> "document" (if it thinks that the resources are as important as characters >>>>> and tags inside the HTML document), to "non-blocking" (if it thinks that >>>>> they are not important in terms of using the document), or even to >>>>> "deferred" (consider the case of a script tag at the body of the HTML >>>>> loading some analytic script). >>>>> >>>>> If we are to be fine with one particular approach, I think we can >>>>> recommend that. But we do not need to struggle to reach consensus on one >>>>> particular algorithm, because in the proposed approach, servers can correct >>>>> the precedence of mis-prioritized requests under the proposed scheme. >>>>> >>>>> >>>>>> >>>>>> TL;DR: I see this draft as a combination of two proposals: >>>>>> A) a new way to define priority levels/semantics (i.e., "how will the >>>>>> resource be used " rather than "when should you send it") : all for this! >>>>>> Needs more work though, current draft doesn't (fully) >>>>>> support use cases and imo, it should. >>>>>> B) sending those new levels via headers instead of frames: many >>>>>> advantages, and "feels right" >>>>>> Except for the re-prioritization bit... >>>>>> >>>>>> With best regards, >>>>>> Robin >>>>>> >>>>>> >>>>>> On Mon, 8 Jul 2019 at 15:00, Kazuho Oku <kazuhooku@gmail.com> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> Today, Lucas and I have submitted the following draft, that defines >>>>>>> an >>>>>>> HTTP header field for driving prioritization. >>>>>>> >>>>>>> https://datatracker.ietf.org/doc/draft-kazuho-httpbis-priority/ >>>>>>> >>>>>>> In short, the draft defines an end-to-end HTTP header field called >>>>>>> "Priority" for transmitting prioritization hints in absolute values >>>>>>> that have meanings. It is much simpler than the prioritization scheme >>>>>>> of H2 that communicates and uses a "tree". Not only the client, but >>>>>>> also the server can send the prioritization hints, in order to >>>>>>> improve >>>>>>> the way the responses are prioritized. The prioritization scheme is >>>>>>> independent to HTTP versions; it can be used on both H2 and H3 (and >>>>>>> also on H1 for providing hints to intermediaries). >>>>>>> >>>>>>> For more detail, please refer to the draft. >>>>>>> >>>>>>> Background: back in May in London, the QUIC WG had a discussion on if >>>>>>> porting the prioritization scheme of H2 to H3 is the way to go [1]. >>>>>>> >>>>>>> I think there were two major arguments for having something >>>>>>> different: >>>>>>> * Prioritization scheme of H2 is complex, and porting it to H3 >>>>>>> increases the complexity [2]. >>>>>>> * With the H2 scheme, it is hard for the server to tweak the >>>>>>> prioritization tree, because clients build their trees in their own >>>>>>> ways [3][4]. >>>>>>> >>>>>>> The arguments against were: >>>>>>> * Redesigning prioritization for H3 is likely to delay the >>>>>>> standardization and time-to-market. >>>>>>> * Having something different in H3 is an act of "adding" complexity >>>>>>> to >>>>>>> HTTP as a whole. >>>>>>> >>>>>>> This discussion has led us to wonder if there could be a technical >>>>>>> solution that resolves the issues of the H2 scheme (see the pro >>>>>>> arguments), at the same time minimizing the downsides. >>>>>>> >>>>>>> And we came up with this proposal. I think the key selling points of >>>>>>> the proposal are: >>>>>>> >>>>>>> * Much simpler thanks to each request carrying an absolute priority >>>>>>> value. No need to synchronize a "tree". >>>>>>> * Because the priority value sent by the client indicates how each >>>>>>> request / response affects the use of other responses (e.g., >>>>>>> "blocking", "non-blocking"), the server can understand the intent of >>>>>>> the client and further optimize the delivery order. >>>>>>> * Use of the HTTP header field as the conveyer of the priority value >>>>>>> allows an origin server to indicate hints to an intermediary that >>>>>>> terminates the H2/H3 connections from the client. For example, an >>>>>>> origin server can indicate higher precedence for some images that >>>>>>> matter more to the user, while giving lower precedence to others. >>>>>>> * Another benefit of using an HTTP header field instead of a frame is >>>>>>> that prioritization logic becomes independent from HTTP versions. >>>>>>> That >>>>>>> would help both clients and servers improve the quality of their >>>>>>> implementation, as well as fostering website owners fine-tune the >>>>>>> prioritization through the use of the Priority response header. >>>>>>> * A header-based prioritization scheme can be improved as time goes, >>>>>>> as HTTP headers are extensible by their nature. It also means that a >>>>>>> header-based design can be rolled out at an earlier stage than a >>>>>>> frame-based design. >>>>>>> >>>>>>> To paraphrase, the header-based design provides simplicity, >>>>>>> extensibility, room to evolve, and the possibility to roll out early. >>>>>>> This could be the only prioritization scheme for H3. Separating >>>>>>> prioritization into a version-independent approach simplifies H3, >>>>>>> taking some load away from QUIC WG. >>>>>>> >>>>>>> Of course, H3 needs to hit the market with a prioritization scheme, >>>>>>> we >>>>>>> need to agree on that particular scheme. But I think we might be able >>>>>>> to agree on the need for a header-based prioritization scheme, that a >>>>>>> server can tweak, that uses absolute priorities. If that is the case, >>>>>>> I think we have fair chance on agreeing on something pretty soon. >>>>>>> >>>>>>> To summarize, with the proposed design, I think we have the chance of >>>>>>> making prioritization better as we roll out HTTP/3, without getting >>>>>>> the standardization process delayed. >>>>>>> >>>>>>> Please let us know what you think. Thank you in advance. >>>>>>> >>>>>>> >>>>>>> [1] >>>>>>> https://github.com/quicwg/wg-materials/blob/master/interim-19-05/priorities.pdf >>>>>>> [2] https://github.com/quicwg/base-drafts/issues/2739 >>>>>>> [3] https://github.com/quicwg/base-drafts/issues/2740 >>>>>>> [4] In >>>>>>> https://lists.w3.org/Archives/Public/ietf-http-wg/2019JulSep/0008.html >>>>>>> , >>>>>>> Robin points out that server intervention is necessary for best >>>>>>> performance. >>>>>>> >>>>>>> ---------- Forwarded message --------- >>>>>>> From: <internet-drafts@ietf.org> >>>>>>> Date: 2019年7月8日(月) 21:51 >>>>>>> Subject: New Version Notification for >>>>>>> draft-kazuho-httpbis-priority-00.txt >>>>>>> To: Kazuho Oku <kazuhooku@gmail.com>, Lucas Pardue < >>>>>>> lucaspardue.24.7@gmail.com> >>>>>>> >>>>>>> >>>>>>> >>>>>>> A new version of I-D, draft-kazuho-httpbis-priority-00.txt >>>>>>> has been successfully submitted by Kazuho Oku and posted to the >>>>>>> IETF repository. >>>>>>> >>>>>>> Name: draft-kazuho-httpbis-priority >>>>>>> Revision: 00 >>>>>>> Title: The Priority HTTP Header Field >>>>>>> Document date: 2019-07-08 >>>>>>> Group: Individual Submission >>>>>>> Pages: 9 >>>>>>> URL: >>>>>>> >>>>>>> https://www.ietf.org/internet-drafts/draft-kazuho-httpbis-priority-00.txt >>>>>>> Status: >>>>>>> https://datatracker.ietf.org/doc/draft-kazuho-httpbis-priority/ >>>>>>> Htmlized: >>>>>>> https://tools.ietf.org/html/draft-kazuho-httpbis-priority-00 >>>>>>> Htmlized: >>>>>>> https://datatracker.ietf.org/doc/html/draft-kazuho-httpbis-priority >>>>>>> >>>>>>> >>>>>>> Abstract: >>>>>>> This document describes the Priority HTTP header field. This >>>>>>> header >>>>>>> field can be used by endpoints to specify the absolute precedence >>>>>>> of >>>>>>> an HTTP response in an HTTP-version-independent way. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please note that it may take a couple of minutes from the time of >>>>>>> submission >>>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>>> >>>>>>> The IETF Secretariat >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Kazuho Oku >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> Robin Marx >>>>>> PhD researcher - web performance >>>>>> Expertise centre for Digital Media >>>>>> >>>>>> T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 >>>>>> >>>>>> www.uhasselt.be >>>>>> Universiteit Hasselt - Campus Diepenbeek >>>>>> Agoralaan Gebouw D - B-3590 Diepenbeek >>>>>> Kantoor EDM-2.05 >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Kazuho Oku >>>>> >>>> >>>> >>>> -- >>>> >>>> Robin Marx >>>> PhD researcher - web performance >>>> Expertise centre for Digital Media >>>> >>>> T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 >>>> >>>> www.uhasselt.be >>>> Universiteit Hasselt - Campus Diepenbeek >>>> Agoralaan Gebouw D - B-3590 Diepenbeek >>>> Kantoor EDM-2.05 >>>> >>>> >>>> >>> >>> -- >>> Kazuho Oku >>> >> >> >> -- >> >> Robin Marx >> PhD researcher - web performance >> Expertise centre for Digital Media >> >> T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 >> >> www.uhasselt.be >> Universiteit Hasselt - Campus Diepenbeek >> Agoralaan Gebouw D - B-3590 Diepenbeek >> Kantoor EDM-2.05 >> >> >> > > -- > Kazuho Oku > -- Robin Marx PhD researcher - web performance Expertise centre for Digital Media T +32(0)11 26 84 79 - GSM +32(0)497 72 86 94 www.uhasselt.be Universiteit Hasselt - Campus Diepenbeek Agoralaan Gebouw D - B-3590 Diepenbeek Kantoor EDM-2.05
Received on Thursday, 11 July 2019 10:15:54 UTC