71333 - need abstract nsIHTTPTransaction from nsIHTTPChannel

Status: VERIFIED FIXED

(Core Graveyard :: Embedding: APIs, defect)

Description

[Judson Valeski]

This new iface would include the following (and be based on existing
functionality in nsIHTTPChannel):
request header access
request method
response header access
response code access
response code string access
enumeration for responses/requests these types are nsIHTTPHeader
removal of atoms in favor of const char *.

Comment 1

[Darin Fisher]

Attachment: nsIHTTPTransaction.idl (initial cut)

Comment 2

[Michael Dunn]

Correction: Changing QA contact for the Embed API bugs to David Epstein.

Comment 3

[Darin Fisher]

my changes for bug 76866 will fix this as well.

Comment 4

[Darin Fisher]

fixed with http branch landing.

nsIHTTPTransaction -> revised nsIHttpChannel

Comment 5

[David Epstein]

per questions about #6 & #7, I'm reopening. If OK, I'll verify. also, I noticed 
in your patch that methods were inheriting from nsISupports, whereas in the 
nsIHttpChannel.idl, the iface inherits from nsIChannel. Is that OK?

In nsIHTTPChannel, I checked against what was entered in API Review Notes:
1) request header access: getRequestHeader() is in there.
2) request method: attribute requestMethod in there.
3) response header access: getResponseHeader() in there.
4) response code access: responseStatus attribute in there.
5) response code string access: responseStatusText attribute (string type).
6) enumeration for responses/requests these types are nsIHTTPHeader: Q: are 
these the const values for referrerType?
7) removal of atoms in favor of const char *: no atoms, but no const char * 
either (Q: is this OK).

Comment 6

[Darin Fisher]

no.. this bug was fixed.

Comment 7

[David Epstein]

verifying