|
1 // Copyright (c) 2008-2009 Nokia Corporation and/or its subsidiary(-ies). |
|
2 // All rights reserved. |
|
3 // This component and the accompanying materials are made available |
|
4 // under the terms of "Eclipse Public License v1.0" |
|
5 // which accompanies this distribution, and is available |
|
6 // at the URL "http://www.eclipse.org/legal/epl-v10.html". |
|
7 // |
|
8 // Initial Contributors: |
|
9 // Nokia Corporation - initial contribution. |
|
10 // |
|
11 // Contributors: |
|
12 // |
|
13 // Description: |
|
14 // |
|
15 |
|
16 #ifndef __RHTTPMESSAGEPARSER_H__ |
|
17 #define __RHTTPMESSAGEPARSER_H__ |
|
18 |
|
19 #include <e32base.h> |
|
20 |
|
21 class CHttpMessageParser; |
|
22 class MHttpMessageParserObserver; |
|
23 |
|
24 class RHttpMessageParser |
|
25 /** |
|
26 The RHttpMessageParser class provides parsing functionality for HTTP/1.1 |
|
27 messages as defined in RFC2616. The HTTP/1.1 protocol specifies that the CR |
|
28 LF sequence is the end of line (eol) marker for all protocol elements except |
|
29 the entity-body. The parser tolerates some deviation from this, as the RFC |
|
30 recommends in section 19.3 - a LF without the leading CR can also be parsed |
|
31 as an eol marker. |
|
32 |
|
33 The parser does not process any header fields. Therefore it needs to be told |
|
34 if an entity body is expected. If one is then the parser needs to know if it |
|
35 is chunk-encoded and if not what the expected size is. |
|
36 |
|
37 With a chunked entity body the parser de-chunks the body data - the observer |
|
38 does not need to parse a chunked body. |
|
39 |
|
40 The parser needs an observer (MHttpMessageParserObserver). The observer |
|
41 supplies the buffers containing the unparsed http message data. The observer |
|
42 must ensure that the buffers it supplies to the parser remain valid until the |
|
43 parser notifies it that it has parsed the entire contents of that buffer. |
|
44 |
|
45 The parser is initially in the Idle state waiting to be notified of available |
|
46 meesage data. When it is notified, the parser obtains the data and moves |
|
47 into the ParsingStartLine state. |
|
48 |
|
49 Whichever state it is in, the parser will notify the observer when it has |
|
50 parsed the entire contents of the current data buffer. It will then wait to |
|
51 be told that there is more data available. When it has been given the next |
|
52 part of the message data it continues parsing. |
|
53 |
|
54 In the ParsingStartLine state the parser looks for the first eol marker. |
|
55 This delimits the start-line. Once found the observer is notified and the |
|
56 parser moves into the ParsingHeaders state. |
|
57 |
|
58 In the ParsingHeaders state the parser searches for header field lines. |
|
59 These lines are delimited by eol markers. In HTTP/1.1 it is possible to fold |
|
60 header field values over multiple lines if the continuation line is followed |
|
61 by a SP or HT. In this case the eol marker is part of LWS and is ignored. |
|
62 Also any eol markers that are part of LWS are omitted from the header field |
|
63 data given to the observer. |
|
64 |
|
65 The header field section is completed once an empty line is parsed. The |
|
66 observer is informed and it should supply the parser with the necessary |
|
67 info about the entity body. If no entity body is expected then the parser |
|
68 moves to the MessageComplete state. If a non-encoded entity body is expected |
|
69 then the parser moves to the ReadingBodyData state. If a chunk-encoded |
|
70 entity body is expected then the parser moves to the ParsingChunkSize state. |
|
71 |
|
72 In the ReadingBodyData state the parser extracts the specified length of |
|
73 entity body data. The observer is notified of each chunk body data parsed. |
|
74 It is possible for the entity body data to be received in several parts due |
|
75 to segmentation at the transport layer, Once all the entity body data has |
|
76 been received the parser notifies the observer that the entity body is |
|
77 complete. The parser moves to MessageComplete state. |
|
78 |
|
79 Note that although the parser will have notified the obserer that it has |
|
80 finished with the current data packet that held some entity body data, the |
|
81 observer should only release that data packet once it itself has no more use |
|
82 for the entity body data it has been given. Failure to do this will result |
|
83 in the buffer containing the received entity body chunks being invalid. The |
|
84 same is true when receiving a chunked entity body. |
|
85 |
|
86 In the ParsingChunkSize the parser searches for a chunk-size component as |
|
87 defined in RFC2616 section 3.6.1. The chunk-size component is delimited by |
|
88 an eol marker. An optional chunk-extension component can be present between |
|
89 the chunk-size and the eol marker - the parser will ignore any |
|
90 chunk-extension components. The chunk-size is a hex number specifying the |
|
91 size of the subsequent chunk-data component. A chunk-size of value zero |
|
92 indicates a last-chunk token - there are no subsequent chunk-data components |
|
93 and the parser moves to the ParsingTrailerHeaders state. A chunk-size of any |
|
94 other value indicates a subsequent chunk-data component and the parser moves |
|
95 to the ParsingChunkData state. |
|
96 |
|
97 In the ParsingChunkData state the parser extracts the length of entity body |
|
98 data specified in the preceeding chunk-size component. The observer is |
|
99 notified of each chunk of entity body data. Note that a chunk-data component |
|
100 can be segmented in the transport layer resulting in the observer being |
|
101 notified more than once for a given chunk-data component. The observer will |
|
102 not notice any disparate behaviour between receiving an entity body that has |
|
103 not been chunk-encoded and one that has. Once the entire chunk-data has been |
|
104 received the parser moves to the ParsingChunkSize state. |
|
105 |
|
106 The ParsingTrailerHeaders state is very similar to the ParsingHeaders state. |
|
107 The observer is notified of each header field and the trailer headers |
|
108 section is delimited by an empty line. The observer is notified of the end |
|
109 of the trailer headers section and the parser moves to MessageComplete state. |
|
110 |
|
111 In the MessageComplete state the parser notifies the observer that the |
|
112 message is complete. The observer is presented with any remaining data in |
|
113 the current data packet. This can be either excess data indicating a mal- |
|
114 formed message or the start of a pipelined message. In either case if the |
|
115 observer wishes to use that data it must not release the current data packet |
|
116 as that will invalidate the data. |
|
117 @see MHttpMessageParserObserver |
|
118 */ |
|
119 { |
|
120 public: // methods |
|
121 |
|
122 inline RHttpMessageParser(); |
|
123 |
|
124 IMPORT_C void OpenL(MHttpMessageParserObserver& aObserver); |
|
125 IMPORT_C void Close(); |
|
126 IMPORT_C void ReceivedMessageData(); |
|
127 IMPORT_C void CompletedBodyDataL(); |
|
128 IMPORT_C void Reset(); |
|
129 IMPORT_C void Flush (); |
|
130 IMPORT_C TBool CompleteMessage ( const TDesC8& aData ); |
|
131 |
|
132 private: // methods |
|
133 |
|
134 IMPORT_C void Reserved_RHttpMessageParser(); |
|
135 |
|
136 private: // attributes |
|
137 |
|
138 CHttpMessageParser* iImplementation; |
|
139 |
|
140 }; |
|
141 |
|
142 inline RHttpMessageParser::RHttpMessageParser() |
|
143 : iImplementation(NULL) |
|
144 { |
|
145 } |
|
146 |
|
147 #endif // __RHTTPMESSAGEPARSER_H__ |