From kfm-devel Thu Mar 02 23:38:43 2000 From: Graham TerMarsch Date: Thu, 02 Mar 2000 23:38:43 +0000 To: kfm-devel Subject: Question about new KIO X-MARC-Message: https://marc.info/?l=kfm-devel&m=95204031500346 Don't know if this is the best list to ask on but I figured that its at least relevant here. Have this idea toying through the back of my mind here on a new app to create, and wanted to find out if it'd work with the new KIO.... Short version of the app is that it's a website validator. Validating not in the sense of "we check for broken links", but in the sense of "we check to make sure that based on the headers provided, you got the right response". I do a lot of work for my customers turning their Webservers into App servers, and find that I'm spending a ton of time sitting at a cmd prompt telnetting directly to the http port and feeding it a raw HTTP request to see if the results that come back are what I expected. What I'm wondering.....is whether or not the new KIO (specifically kio_http) can provide me a low enough level of access to the request and response that I can: 1) Specify the exact contents of the headers that I want to send to the webserver. 2) Get access to the full header information of the response received. In the event of a http redirect, I need to be able to query the response _before_ any redirect is actually done (I need to see if I'm being redirected to the right place). Ideally I'd like to be able to do all of this in KDE without having to have any sub-processes of my own that I fire up. But, if what I've outlined above isn't possible I know I'd be able to get away with doing the HTTP request out of a Perl script that'd do the dirty work for me. Either that, or do raw HTTP connections myself (but then it'd be a serious pain when i get around to doing HTTPS stuff). Any suggestions on this one? Will the new KIO let me have access that low to the actual request/response? -- Graham TerMarsch // ----------------------------------------------------------------- // If you know the answer to a question, don't ask. -- Petersen Nesbit // -----------------------------------------------------------------