diff -r 000000000000 -r f5a58ecadc66 servicediscoveryandcontrol/pnp/test/upnp/upnpmessage/inc/rhttpmessageparser.h --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/servicediscoveryandcontrol/pnp/test/upnp/upnpmessage/inc/rhttpmessageparser.h Tue Feb 02 01:12:20 2010 +0200 @@ -0,0 +1,147 @@ +// Copyright (c) 2008-2009 Nokia Corporation and/or its subsidiary(-ies). +// All rights reserved. +// This component and the accompanying materials are made available +// under the terms of "Eclipse Public License v1.0" +// which accompanies this distribution, and is available +// at the URL "http://www.eclipse.org/legal/epl-v10.html". +// +// Initial Contributors: +// Nokia Corporation - initial contribution. +// +// Contributors: +// +// Description: +// + +#ifndef __RHTTPMESSAGEPARSER_H__ +#define __RHTTPMESSAGEPARSER_H__ + +#include + +class CHttpMessageParser; +class MHttpMessageParserObserver; + +class RHttpMessageParser +/** +The RHttpMessageParser class provides parsing functionality for HTTP/1.1 +messages as defined in RFC2616. The HTTP/1.1 protocol specifies that the CR +LF sequence is the end of line (eol) marker for all protocol elements except +the entity-body. The parser tolerates some deviation from this, as the RFC +recommends in section 19.3 - a LF without the leading CR can also be parsed +as an eol marker. + +The parser does not process any header fields. Therefore it needs to be told +if an entity body is expected. If one is then the parser needs to know if it +is chunk-encoded and if not what the expected size is. + +With a chunked entity body the parser de-chunks the body data - the observer +does not need to parse a chunked body. + +The parser needs an observer (MHttpMessageParserObserver). The observer +supplies the buffers containing the unparsed http message data. The observer +must ensure that the buffers it supplies to the parser remain valid until the +parser notifies it that it has parsed the entire contents of that buffer. + +The parser is initially in the Idle state waiting to be notified of available +meesage data. When it is notified, the parser obtains the data and moves +into the ParsingStartLine state. + +Whichever state it is in, the parser will notify the observer when it has +parsed the entire contents of the current data buffer. It will then wait to +be told that there is more data available. When it has been given the next +part of the message data it continues parsing. + +In the ParsingStartLine state the parser looks for the first eol marker. +This delimits the start-line. Once found the observer is notified and the +parser moves into the ParsingHeaders state. + +In the ParsingHeaders state the parser searches for header field lines. +These lines are delimited by eol markers. In HTTP/1.1 it is possible to fold +header field values over multiple lines if the continuation line is followed +by a SP or HT. In this case the eol marker is part of LWS and is ignored. +Also any eol markers that are part of LWS are omitted from the header field +data given to the observer. + +The header field section is completed once an empty line is parsed. The +observer is informed and it should supply the parser with the necessary +info about the entity body. If no entity body is expected then the parser +moves to the MessageComplete state. If a non-encoded entity body is expected +then the parser moves to the ReadingBodyData state. If a chunk-encoded +entity body is expected then the parser moves to the ParsingChunkSize state. + +In the ReadingBodyData state the parser extracts the specified length of +entity body data. The observer is notified of each chunk body data parsed. +It is possible for the entity body data to be received in several parts due +to segmentation at the transport layer, Once all the entity body data has +been received the parser notifies the observer that the entity body is +complete. The parser moves to MessageComplete state. + +Note that although the parser will have notified the obserer that it has +finished with the current data packet that held some entity body data, the +observer should only release that data packet once it itself has no more use +for the entity body data it has been given. Failure to do this will result +in the buffer containing the received entity body chunks being invalid. The +same is true when receiving a chunked entity body. + +In the ParsingChunkSize the parser searches for a chunk-size component as +defined in RFC2616 section 3.6.1. The chunk-size component is delimited by +an eol marker. An optional chunk-extension component can be present between +the chunk-size and the eol marker - the parser will ignore any +chunk-extension components. The chunk-size is a hex number specifying the +size of the subsequent chunk-data component. A chunk-size of value zero +indicates a last-chunk token - there are no subsequent chunk-data components +and the parser moves to the ParsingTrailerHeaders state. A chunk-size of any +other value indicates a subsequent chunk-data component and the parser moves +to the ParsingChunkData state. + +In the ParsingChunkData state the parser extracts the length of entity body +data specified in the preceeding chunk-size component. The observer is +notified of each chunk of entity body data. Note that a chunk-data component +can be segmented in the transport layer resulting in the observer being +notified more than once for a given chunk-data component. The observer will +not notice any disparate behaviour between receiving an entity body that has +not been chunk-encoded and one that has. Once the entire chunk-data has been +received the parser moves to the ParsingChunkSize state. + +The ParsingTrailerHeaders state is very similar to the ParsingHeaders state. +The observer is notified of each header field and the trailer headers +section is delimited by an empty line. The observer is notified of the end +of the trailer headers section and the parser moves to MessageComplete state. + +In the MessageComplete state the parser notifies the observer that the +message is complete. The observer is presented with any remaining data in +the current data packet. This can be either excess data indicating a mal- +formed message or the start of a pipelined message. In either case if the +observer wishes to use that data it must not release the current data packet +as that will invalidate the data. +@see MHttpMessageParserObserver +*/ + { +public: // methods + + inline RHttpMessageParser(); + + IMPORT_C void OpenL(MHttpMessageParserObserver& aObserver); + IMPORT_C void Close(); + IMPORT_C void ReceivedMessageData(); + IMPORT_C void CompletedBodyDataL(); + IMPORT_C void Reset(); + IMPORT_C void Flush (); + IMPORT_C TBool CompleteMessage ( const TDesC8& aData ); + +private: // methods + + IMPORT_C void Reserved_RHttpMessageParser(); + +private: // attributes + + CHttpMessageParser* iImplementation; + + }; + +inline RHttpMessageParser::RHttpMessageParser() +: iImplementation(NULL) + { + } + +#endif // __RHTTPMESSAGEPARSER_H__