Re: [twsocket] THttpServer - How to handle unimplemented request methods
On 11-09-2010 09:22, Angus Robertson - Magenta Systems Ltd wrote: What is the purpose of the OPTIONS method? From http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html "The OPTIONS method represents a request for information about the communication options available on the request/response chain identified by the Request-URI. This method allows the client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval. " I'm using to enable CORS (Cross-Origin Resource Sharing) http://dev.w3.org/2006/waf/access-control/ Requests for mime types other than text/plain, must be "preflighted", and browsers use the OPTIONS method request to execute this "preflight" query. http://hacks.mozilla.org/2009/07/cross-site-xmlhttprequest-with-cors/ https://developer.mozilla.org/En/HTTP_access_control Rui -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpServer - How to handle unimplemented request methods
> But, why don't keep the naming schema? TriggerAfterProcessRequest ( > and respective OnAfterProcessRequest) would be less confuse. The event is between two processing stages, so could be named after one or before the other. What is the purpose of the OPTIONS method? Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpServer - How to handle unimplemented request methods
RTT wrote: > Done. I've now sent you a PM with the .diff file. Thanks. -- Arno Garrels -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpServer - How to handle unimplemented request methods
Done. I've now sent you a PM with the .diff file. Feel free to apply your changes to the latest SVN revision and send me the patch file by PM. Changes MUST not break existing code and a change log in unit's comment section was helpful too. -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpServer - How to handle unimplemented request methods
Thank you for the explanation Angus. But, why don't keep the naming schema? TriggerAfterProcessRequest ( and respective OnAfterProcessRequest) would be less confuse. Rui -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpServer - How to handle unimplemented request methods
RTT wrote:
> On 10-09-2010 16:43, Arno Garrels wrote:
>>> Another thing that would be useful, if added to the code base of the
THttpConnection, is the possibility to send additional headers
from the THttpConnection.SendDocument, to define cache control,
etc.. procedure THttpConnection.SendDocument(SendType :
THttpSendType; const aHeader:string='');
...
if FLastModified<> 0 then
Header := Header + 'Last-Modified: ' +
RFC1123_Date(FLastModified) + ' GMT' + #13#10;
if ContEncoderHdr<> '' then
Header := Header + ContEncoderHdr; { V7.20 }
if aHeader> '' then
Header := Header + aHeader
Header := Header + GetKeepAliveHdrLines + #13#10;
...
>> Useful as well, probably the parameter should be named
>> "CustomHeaders", it's a bit confusing since one has to know which
>> headers are added
>> by the method.
>>
> To complement this, a global PersistentHeader property, to provide a
> mean to specify header items that should be sent in every response,
> can be useful too.
>
> Another useful change. How about setting the NameValueSeparator of the
> FRequestHeader stringlist to ':' ?
>
> constructor THttpConnection.Create(AOwner: TComponent);
> ...
> FRequestHeader := TStringList.Create;
> FRequestHeader.NameValueSeparator:= ':';
> ...
>
> This way it's easy to check the value of any of the received headers
> by only typing trim(RequestHeader.values[e.g. 'Origin',...])
> Yes, I can do it at any time from my code, but won't hurt if done
> internally. The default '=' NameValueSeparator is there already, so
> why not use the correct one?
Feel free to apply your changes to the latest SVN revision and send me
the patch file by PM. Changes MUST not break existing code and a change
log in unit's comment section was helpful too.
--
Arno Garrels
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] THttpServer - How to handle unimplemented request methods
> Is there any simple way to handle other than the GET, POST and HEADER > request methods,... as OPTIONS,...? You'd currently have to override the entire ProcessRequest procedure to add a new method. > > By the way, the TriggerBeforeAnswer is used in what scenarios? > > From > > the code above, it seems the answer has been delivered already. > Indeed, maybe Angus can answer it, he added it? >From the notes in the code: Added OnBeforeAnswer event triggered once the answer is prepared but before it is sent from ProcessRequest. Added OnAfterAnswer triggered after the answer is sent from ConnectionDataSent so time taken to send reply can be logged. AfterAnswer is where the W3C web is written, once all the response data has been sent, which may take several seconds or hours if it's ISO image file. BeforeAnswer was intended to allow this time to be calculated exactly, but after the response has been composed, which may take several seconds on SQL lookups. BeforeProcessRequest is before page processing, BeforeAnswer is after, but before the message handler starts sending the response. Currently, I start the request duration counter in BeforeProcessRequest and ignore BeforeAnswer, and time SQL requests separately to another log. Angus -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
Re: [twsocket] THttpServer - How to handle unimplemented request methods
On 10-09-2010 16:43, Arno Garrels wrote:
Another thing that would be useful, if added to the code base of the
> THttpConnection, is the possibility to send additional headers from
> the THttpConnection.SendDocument, to define cache control, etc..
> procedure THttpConnection.SendDocument(SendType : THttpSendType; const
> aHeader:string='');
> ...
> if FLastModified<> 0 then
> Header := Header + 'Last-Modified: ' +
> RFC1123_Date(FLastModified) + ' GMT' + #13#10;
> if ContEncoderHdr<> '' then
> Header := Header + ContEncoderHdr; { V7.20 }
> if aHeader> '' then
> Header := Header + aHeader
> Header := Header + GetKeepAliveHdrLines + #13#10;
> ...
Useful as well, probably the parameter should be named "CustomHeaders",
it's a bit confusing since one has to know which headers are added
by the method.
To complement this, a global PersistentHeader property, to provide a
mean to specify header items that should be sent in every response, can
be useful too.
Another useful change. How about setting the NameValueSeparator of the
FRequestHeader stringlist to ':' ?
constructor THttpConnection.Create(AOwner: TComponent);
...
FRequestHeader := TStringList.Create;
FRequestHeader.NameValueSeparator:= ':';
...
This way it's easy to check the value of any of the received headers by
only typing trim(RequestHeader.values[e.g. 'Origin',...])
Yes, I can do it at any time from my code, but won't hurt if done
internally. The default '=' NameValueSeparator is there already, so why
not use the correct one?
Rui
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
Re: [twsocket] THttpServer - How to handle unimplemented request methods
RTT wrote:
> Hi everyone!
>
> Is there any simple way to handle other than the GET, POST and HEADER
> request methods,... as OPTIONS,...?
> The way it is now, the THttpConnection.ProcessRequest procedure always
> respond with a Answer501, not giving any chance to handle other
> methods. I think a TriggerOnUnknownMethod event would be very useful.
I think so as well, should be named TriggerUnknownMethod and event
OnUnknowMethod.
> By the way, the TriggerBeforeAnswer is used in what scenarios? From
> the code above, it seems the answer has been delivered already.
Indeed, maybe Angus can answer it, he added it?
>
> Another thing that would be useful, if added to the code base of the
> THttpConnection, is the possibility to send additional headers from
> the THttpConnection.SendDocument, to define cache control, etc..
> procedure THttpConnection.SendDocument(SendType : THttpSendType; const
> aHeader:string='');
> ...
> if FLastModified <> 0 then
> Header := Header + 'Last-Modified: ' +
> RFC1123_Date(FLastModified) + ' GMT' + #13#10;
> if ContEncoderHdr <> '' then
> Header := Header + ContEncoderHdr; { V7.20 }
> if aHeader > '' then
> Header := Header + aHeader
> Header := Header + GetKeepAliveHdrLines + #13#10;
> ...
Useful as well, probably the parameter should be named "CustomHeaders",
it's a bit confusing since one has to know which headers are added
by the method.
--
Arno Garrels
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
