ResourceResponseBase has a number of accessors for processed versions of HTTP headers. I'd like to use these from chromium code that only has a handle to WebURLResponse so I want to plumb them through.
Created attachment 142808 [details] Patch
Please wait for approval from abarth@webkit.org, dglazkov@chromium.org, fishd@chromium.org, jamesr@chromium.org or tkent@chromium.org before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.
One thing I'm unsure of is how to decide what to expose. This patch is minimal; I only exposed what I need for https://chromiumcodereview.appspot.com/10387200 Alternately, I could expose every RRB accessor, or just every RRB accessor from this block that I grabbed most of these from. Thoughts?
Hmm...so some WebCore code is doing network fetches via Resource*, which then calls out to chromium via Platform WebURL*. The response then comes back in and is piped back in to WebCore which makes calls on its client which then pipes back out to chromium. Then in chromium code you want to grab fields off of the WebURLResponse which is wrapping the WebCore::ResourceResponse which is wrapping the data passed in via WebKit API earlier on the stack... Seems to be a whole lotta bouncing back and forth. Is this the right place to hook in for this data?
(In reply to comment #4) > Hmm...so some WebCore code is doing network fetches via Resource*, which then calls out to chromium via Platform WebURL*. The response then comes back in and is piped back in to WebCore which makes calls on its client which then pipes back out to chromium. Then in chromium code you want to grab fields off of the WebURLResponse which is wrapping the WebCore::ResourceResponse which is wrapping the data passed in via WebKit API earlier on the stack... > > Seems to be a whole lotta bouncing back and forth. Is this the right place to hook in for this data? Hell if I know. I agree that there's a whole lotta bouncing around. Both this and my previous webkit CL (issue 86522) are 100% motivated by the fact that the current architecture of everything has data flowing like: webkit/media <-- WebKit <-- net/http (where the outer two elements are chromium). If webkit/media could access the net/http response headers/object I'd be happy as a clam and no webkit changes would be necessary. But AFAICT the above data flow is WorkingAsIntended, and the fact that webkit/media can't poke through to the net/http layer is intentional. I'm open to other suggestions if you/others have any...
Created attachment 142845 [details] Patch
I'm going to defer to James and/or fishd for this patch.
Discussed w/ Darin Fisher and decided these accessors are not necessarily the API WebKit wants to expose. Instead, implemented everything I need in terms of chromium changes (see https://chromiumcodereview.appspot.com/10387200, patchset #3 and later). Closing as WONTFIX.