3.2.5.2 Receiving a PushStart Request

The server MUST validate that the HTTP request line and the HTTP message headers adhere to the syntax for PushStart requests (section 2.2.2.2). If the validation fails, the server MUST respond with a valid HTTP error status code as specified in [RFC2616].

If the higher layer requires the client to authenticate itself, the server MUST process the Authorization header (as specified in [RFC2616] section 14.8), if it is present in the request. If the server is acting as a proxy server, it MUST process the Proxy-Authorization header (as specified in [RFC2616] section 14.34) instead of the Authorization header.<11>

Note NTLM authentication is not supported in the PushStart request.

If it is necessary to send an authentication challenge to the client (for example, because the Authorization header was missing or specified incorrect credentials), the server MAY use one of the authentication schemes that the client listed on the X-Accept-Authentication header in the request, if that header is present.

If the server sends an authentication challenge to the client, it MUST be specified by using the WWW-Authenticate header (as specified in [RFC2616] section 14.47), and the status code of the response MUST be 401. If the server is acting as a proxy server, it MUST specify the Proxy-Authenticate header (as specified in [RFC2616] section 14.33) instead of the WWW-Authenticate header, and the status code of the response MUST be 407.<12>

After having sent a response with status codes 401 or 407 the server SHOULD NOT close the TCP connection to the client. The Idle-Timeout timer MUST be started if it is not already running or restarted if it is already running.

If the server is not sending a response with an error status code, the server MUST load the state that has a Push-ID variable with the same value as the value of the push-id (section 2.2.1.3.1) cookie on the Cookie header. If the matching state cannot be found, or if the client did not specify a push-id cookie, this MUST be treated as an error.<13> The server MUST respond to the client with a valid HTTP error status code as specified in [RFC2616]. If the matching state is found and the server is currently receiving streaming data from the client on another TCP connection (that is, a previous PushStart request is still in progress), this is an error situation. In this case, the server MUST respond to the new PushStart request with a valid HTTP error status code as specified in [RFC2616].

The server MUST check with the higher layer that the URL that the client specified in the request is valid. If the URL is invalid, this is an error, and the server MUST respond with a valid HTTP error status code as specified in [RFC2616].

The Idle-Timeout and Inactivity-Timeout timer MUST be stopped.

If the server is sending a response with an error status code, or if the entire message body of the PushStart request has been received, as determined by the Content-Length header (as specified in [RFC2616] section 14.13), the server MUST send a PushStart response. How to send a PushStart response is specified in section 3.2.5.2.1.

Otherwise, the Idle-Timeout timer MUST be started, and the server MUST wait for a higher-layer triggered event or one of the packet types specified in section 2.2.3 to be received as part of the HTTP message body. If this is the first PushStart request received for this session, the first packet MUST be an $H packet.

How to process a $C packet is specified in section 3.2.5.6. How to process a $D packet is specified in section 3.2.5.4. How to process an $E packet is specified in section 3.2.5.5. How to process an $F packet is specified in section 3.2.5.7. How to process an $H packet is specified in section 3.2.5.3.