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

[bugzilla-daemon at webkit.org]

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





------- Comment #13 from dmeketa at adobe.com  2007-03-13 20:44 PDT -------
Through plugin-futures, I have been informed that version 17, which I had been
using, has already been taken, for a feature called NPRuntime object
enumeration.  I have entered bug 13064 to track that as an enhancement request.
 When I submit my next patch (ah, how these things can take longer than one
expects), I will be declaring version 18.

This is actually a little hairier than the other version skips I discuss in
comment #4.  Version 17 added both NPN_Enumerate and NPClass::enumerate.  I
really don't want the HTTP header work to get hung up waiting for NPRuntime
enumeration, and I don't have the time or expertise to code NPRuntime
enumeration, so I think I've found a simple workaround: declare version 18 in
NPN_Version and NPNetscapeFuncs::version, but fill in
NPNetscapeFuncs::enumerate as NULL, and declare version 1 (rather than 2) for
NPClass::structVersion.  This will mean that plugins can only run into trouble
if they blindly switch on NPN_Version, without checking that
NPNetscapeFuncs::enumerate is non-NULL, or without checking that
NPClass::structVersion is >= 2.  In addition, I'm not sure there are any
plugins out there that could be using this yet; AFAIK it has not yet landed in
any shipping browsers, so any plugins attempting to use this will hopefully see
WebKit having this stub implementation before they release anything depending
on a real implementation.

This is definitely less than ideal, but similar things have happened in many
browsers due to the NPAPI's lousy flat versioning scheme.  On the bright side,
bug 13064 is probably worth fixing anyway, and if it is, then that's one less
lie that our NPN_Version will be telling.  (It is already telling several.)


-- 
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.