Zend_Wildfire_Channel_HttpHeadersImplements interfaces:
Implements communication via HTTP request and response headers for Wildfire Protocols.
Located in /Wildfire/Channel/HttpHeaders.php (line 50)
Zend_Controller_Plugin_Abstract | --Zend_Wildfire_Channel_HttpHeaders
static integer
$_controllerPluginStackIndex
= 999 (line 68)
The index of the plugin in the controller dispatch loop plugin stack
static string
$_headerPrefix
= 'X-WF-' (line 56)
The string to be used to prefix the headers.
static Zend_Wildfire_Channel_HttpHeaders
$_instance
= null (line 62)
Singleton instance
array
$_protocols
= null (line 74)
The protocol instances for this channel
Inherited from Zend_Controller_Plugin_Abstract
Zend_Controller_Plugin_Abstract::$_request
Zend_Controller_Plugin_Abstract::$_response
static destroyInstance (line 136)
Destroys the singleton instance
Primarily used for testing.
static getInstance (line 121)
Get or create singleton instance
static init (line 83)
Initialize singleton instance.
static setControllerPluginStackIndex (line 208)
Set the index of the plugin in the controller dispatch loop plugin stack
dispatchLoopShutdown (line 295)
Flush messages to headers as late as possible but before headers have been sent.
flush (line 181)
Flush all data from all protocols and send all data to response headers.
getProtocol (line 147)
Get the instance of a give protocol for this channel
getRequest (line 306)
Get the request object
getResponse (line 325)
Get the response object
isReady (line 264)
Determine if channel is ready.
The channel is ready as long as the request and response objects are initialized, can send headers and the FirePHP header exists in the User-Agent.
If the header does not exist in the User-Agent, no appropriate client is making this request and the messages should not be sent.
A timing issue arises when messages are logged before the request/response objects are initialized. In this case we do not yet know if the client will be able to accept the messages. If we consequently indicate that the channel is not ready, these messages will be dropped which is in most cases not the intended behaviour. The intent is to send them at the end of the request when the request/response objects will be available for sure.
If the request/response objects are not yet initialized we assume if messages are logged, the client will be able to receive them. As soon as the request/response objects are availoable and a message is logged this assumption is challenged. If the client cannot accept the messages any further messages are dropped and messages sent prior are kept but discarded when the channel is finally flushed at the end of the request.
When the channel is flushed the $forceCheckRequest option is used to force a check of the request/response objects. This is the last verification to ensure messages are only sent when the client can accept them.
_initProtocol (line 165)
Initialize a new protocol
_registerControllerPlugin (line 220)
Register this object as a controller plugin.
Inherited From Zend_Controller_Plugin_Abstract
Zend_Controller_Plugin_Abstract::dispatchLoopShutdown()
Zend_Controller_Plugin_Abstract::dispatchLoopStartup()
Zend_Controller_Plugin_Abstract::getRequest()
Zend_Controller_Plugin_Abstract::getResponse()
Zend_Controller_Plugin_Abstract::postDispatch()
Zend_Controller_Plugin_Abstract::preDispatch()
Zend_Controller_Plugin_Abstract::routeShutdown()
Zend_Controller_Plugin_Abstract::routeStartup()
Zend_Controller_Plugin_Abstract::setRequest()
Zend_Controller_Plugin_Abstract::setResponse()
Documentation generated on Mon, 21 Jun 2010 15:27:44 -0400 by phpDocumentor 1.4.3