[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 #5 from darin at apple.com  2007-03-13 11:54 PDT -------
(In reply to comment #4)
> If we had access to the raw HTTP stream, we could send things through verbatim,

I'd like to address this eventually by requesting a new feature in the
NSURLResponse API. Would you be willing to file a bug about that at
<http://bugreport.apple.com>? In the short term I assume this won't happen but
in the longer term it would be good.

> I'm going for sorting on header names rather than header values, using
> allKeys and sortedArrayUsingSelector:@selector(caseInsensitiveCompare:).

Right. Even though that's not what I said, it *is* what I meant.

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

The only convincing argument in favor of NSString is the appeal appendFormat:.
I think it's wrong, but not terribly so, to convert to and from a UTF-16 string
here. Although NSString looks abstract, really it's effectively UTF-16. I think
it's relatively easy to append to an NSMutableData with appendBytes:length: and
I slightly prefer that approach.

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

Good comment.

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

Wow, we should really implement that. It would be *so* easy. Would you be
willing to file another bug in bugs.webkit.org about this feature?


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