[Webkit-unassigned] [Bug 13029] Permit NPAPI plug-ins to see HTTP response headers

Mon Mar 12 19:41:46 PDT 2007

http://bugs.webkit.org/show_bug.cgi?id=13029

------- Comment #4 from dmeketa at adobe.com  2007-03-12 19:41 PDT -------
(In reply to comment #3)

Thanks Darin.  I'm revising the patch to address these comments and add a test
case, but I'll respond here now in advance of having the next version ready.

> I'm a little concerned that the headers string is in random (dictionary key)
> order. I'd prefer some sort of sorted order. That could be done using
> keysSortedByValueUsingSelector: and then objectEnumerator instead of just
> keyEnumerator.

Fair enough, the order isn't supposed to matter, but stable ordering is a good
thing.  If we had access to the raw HTTP stream, we could send things through
verbatim, but since we must choose an ordering, a stable one seems like a good
idea.  I'm going for sorting on header names rather than header values, using
allKeys and sortedArrayUsingSelector:@selector(caseInsensitiveCompare:).

> It seems a shame that we have to compose this string every time even though
> it's only used for certain headers.

Agreed, but I don't know how to solve this problem, given that we don't have
access to the raw HTTP stream.  We could define a more complex interface via
the NPAPI (get status line, enumerate all headers, get specific header), but
simple seems good for cross-vendor standards, and plugin-futures has already
approved this API, and Opera has already implemented it.  Since the string only
needs to be built once per URL transfer, it doesn't seem likely to have a major
performance impact, but if someone can point to a performance regression, I'll
certainly see what I can do.

> I think it would be better if the headers were in the form of NSData rather
> than NSString.

I'm still learning here, so I'm happy to make this change if someone can give
me a more detailed reason why.  As far as I can tell, though, this choice of
NSData vs. NSString is only used in one place (the interface between
startStreamWithResponse: and startStreamResponseURL:etc), the difference in
container classes is minor, the headers are in this case in fact ASCII text,
and the string classes permit handy manipulation through things like
appendFormat:.  NSString seemed natural to me in these circumstances.  Again,
tell me why I'm being thick, and I'll change it...

> I think we want NSUTF8StringEncoding rather than NSASCIIStringEncoding.

You're probably right.  I've made this change, and added the following comment:

// HACK: pass the headers through as UTF-8.
// This is not the intended behavior; we're supposed to pass original bytes
verbatim.
// But we don't have the original bytes, we have NSStrings built by the URL
loading system.
// It hopefully shouldn't matter, since RFC2616/RFC822 require ASCII-only
headers,
// but surely someone out there is using non-ASCII characters, and hopefully
UTF-8 is adequate here.
// It seems better than NSASCIIStringEncoding, which will lose information if
non-ASCII is used.

> Is it really safe to claim to have features like XPConnect scripting (which we
> almost certainly won't ever implement), form values, and popups enabled state?
> How can the plug-in detect the fact that we don't implement those?

A tricky topic, since the NPAPI versioning system wasn't designed with optional
features in mind.  But I've reassured myself that all the version numbers we're
hopping over are handled safely:

12 (actual) or 13 (documented): XPConnect.  WebKit was already 14 before I came
along, to promise NPRuntime, and the implicit promise of XPConnect doesn't seem
to have done any harm.  I think the reason is that XPConnect starts out with
either the plugin or the browser querying the other for a root XPConnect
object, using NPN_GetValue or NPP_GetValue, and if NULL is returned, the
attempt is aborted.  NULL is the value that comes back for the "I don't
understand that variable" situation.  Anyone not checking for NULL when calling
NPN_GetValue or NPP_GetValue is asking for trouble.

15: Plugin form values.  This actually doesn't seem to promise anything on the
browser's part, only on the plugin's part.  The plugin supports an additional
variable in NPP_GetValue that indicates the plugin's (text-only) value for a
form submission.  And, as above, a plugin is free to return NULL here.

16: Popups enabled state.  This just promises the existence of
NPN_PushPopupsEnabledState and NPN_PopPopupsEnabledState.  My patch includes
stub implementations of these that can safely be called, but don't do anything.
 If anyone wants to implement these for real, enter a separate bug and ask on
plugin-futures for a detailed spec of what they do.  The basic idea is that
they allow a plugin to inform the browser "I'm handling a user input event, so
don't disable popups right now", which is useful because the browser doesn't
know about input events to plugins on some systems, e.g. Windows.  On the Mac,
however, I think all events go through the browser, so it's probably a
non-issue except in WebKit ports.

17: That's this feature, which would end up implemented as promised.

New patch soon, hopefully tomorrow.  Thanks again to anyone who's reading.

-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.