| Author |
Message |
|
Dominic Mark
#1 / 18
|
 ANN: XMLHTTP In ASP The problems of using Microsoft.XMLHTTP inside the ASP environment are resolved in the beta version of MSXML2. The new progid of this object is MSXML2.XMLHTTP. It is used the same way as
the old Microsoft.XMLHTTP.
You can get the beta from http://www.*-*-*.com/
--
Dominic
Read The Docs? http://www.*-*-*.com/
|
| Tue, 15 Apr 2003 01:44:32 GMT |
|
 |
|
#2 / 18
|
ANN: XMLHTTP In ASP
|
| Fri, 19 Jun 1992 00:00:00 GMT |
|
|
|
Ryan N
#3 / 18
|
ANN: XMLHTTP In ASP Also check out the MSXML2.ServerXMLHTTP object which MS developed specifically for server-side and not client-side use. It functions the same as MSXML2.XMLHTTP. --Ryan
______________
This is madness!!!
Quote: > The problems of using Microsoft.XMLHTTP inside the ASP environment are > resolved in the beta version of MSXML2. > The new progid of this object is MSXML2.XMLHTTP. It is used the same way
as
> the old Microsoft.XMLHTTP.
> You can get the beta from http://msdn.microsoft.com/xml.
> --
> Dominic
> Read The Docs? http://msdn.microsoft.com/scripting
|
| Tue, 15 Apr 2003 02:16:49 GMT |
|
|
|
Gerry Hickma
#4 / 18
|
ANN: XMLHTTP In ASP Hi,
This sounds really cool. Do you know if it supports downloading large
zip files using chunking?
Quote:
> Also check out the MSXML2.ServerXMLHTTP object which MS developed
> specifically for server-side and not client-side use. It functions the same
> as MSXML2.XMLHTTP.
> --Ryan
> ______________
> This is madness!!!
> > The problems of using Microsoft.XMLHTTP inside the ASP environment are
> > resolved in the beta version of MSXML2.
> > The new progid of this object is MSXML2.XMLHTTP. It is used the same way
> as
> > the old Microsoft.XMLHTTP.
> > You can get the beta from http://msdn.microsoft.com/xml.
> > --
> > Dominic
> > Read The Docs? http://msdn.microsoft.com/scripting
-- Gerry Hickman (London UK)
|
| Tue, 15 Apr 2003 07:55:58 GMT |
|
|
|
Dominic Mark
#5 / 18
|
ANN: XMLHTTP In ASP From the documentation:
The HTTP client stack offers longer uptimes. WinInet features that are not
critical for server applications, such as URL caching, auto-discovery of
proxy servers, HTTP/1.1 chunking, offline support, and support for gopher
and FTP protocols are not included in the new HTTP subset.
<
--
Dominic
Read The Docs? http://msdn.microsoft.com/scripting
Quote: > Hi, > This sounds really cool. Do you know if it supports downloading large
> zip files using chunking?
> > Also check out the MSXML2.ServerXMLHTTP object which MS developed
> > specifically for server-side and not client-side use. It functions the
same
> > as MSXML2.XMLHTTP.
> > --Ryan
> > ______________
> > This is madness!!!
> > > The problems of using Microsoft.XMLHTTP inside the ASP environment are
> > > resolved in the beta version of MSXML2.
> > > The new progid of this object is MSXML2.XMLHTTP. It is used the same
way
> > as
> > > the old Microsoft.XMLHTTP.
> > > You can get the beta from http://msdn.microsoft.com/xml.
> > > --
> > > Dominic
> > > Read The Docs? http://msdn.microsoft.com/scripting
> --
> Gerry Hickman (London UK)
|
| Wed, 16 Apr 2003 04:29:40 GMT |
|
|
|
Gerry Hickma
#6 / 18
|
ANN: XMLHTTP In ASP Thanks Dominic,
BTW I think you're right about using the Java class. I haven't had a
chance to look at it properly yet - I've been avoiding Java of late, but
you make a good point about the network file access.
I wonder how they made this new XMLHTTP work? Do they use WinInet again,
and if so how did they get round the inherent WinInet APIs being of a
client nature? Does this mean the WinInet API has also been updated, or
have they just managed to use it in a more server orientated way?
Quote:
> From the documentation:
> The HTTP client stack offers longer uptimes. WinInet features that are not
> critical for server applications, such as URL caching, auto-discovery of
> proxy servers, HTTP/1.1 chunking, offline support, and support for gopher
> and FTP protocols are not included in the new HTTP subset.
> <
> --
> Dominic
> Read The Docs? http://msdn.microsoft.com/scripting
> > Hi,
> > This sounds really cool. Do you know if it supports downloading large
> > zip files using chunking?
> > > Also check out the MSXML2.ServerXMLHTTP object which MS developed
> > > specifically for server-side and not client-side use. It functions the
> same
> > > as MSXML2.XMLHTTP.
> > > --Ryan
> > > ______________
> > > This is madness!!!
> > > > The problems of using Microsoft.XMLHTTP inside the ASP environment are
> > > > resolved in the beta version of MSXML2.
> > > > The new progid of this object is MSXML2.XMLHTTP. It is used the same
> way
> > > as
> > > > the old Microsoft.XMLHTTP.
> > > > You can get the beta from http://msdn.microsoft.com/xml.
> > > > --
> > > > Dominic
> > > > Read The Docs? http://msdn.microsoft.com/scripting
> > --
> > Gerry Hickman (London UK)
-- Gerry Hickman (London UK)
|
| Wed, 16 Apr 2003 06:46:39 GMT |
|
|
|
Dominic Mark
#7 / 18
|
ANN: XMLHTTP In ASP Its still WinInet underneath, I don't think they have done anything with it
other than cut out some of the features. Resume is a problem in a lot of
programming areas it seems. For example the MFC doens't have a clear way of
being able to perform resumed downloads.
UPD: Java Class for Networking
It would be very simple. Sun provides everything a networking related
programmer could want. Except an easy way to resume a download. Firstly the
is the URL class, very easy to use for one chunk downloading but it comes
unstuck if you try and use it for chunking. What should have been done is
that the SkipBytes method (seek to a position in a byte stream) should have
been overridden from the foundation class DataInputStream. This would mean
that it would behind the scenes to the skipping using the FTP protocol and
everything would work great. However this is not the case, instead it blocks
all received data until it gets to the specified location, so this is not
really resume.
Sun also provides some excellent packages for working with all sorts of
protocols (ftp, http, smtp, pop3, nntp, imap, gopher ...) However these are:
1.] Not supported by Sun and prohibited for use in products (na)
2.] Not part of the MS JVM and therefore useless.
The second point makes all these not worth knowing about.
I am think now that perhaps a better way of doing it would be for me to
create a java class that was instead executed via the command line. Or more
likely that I drop the Java idea and use a Winsock control.
--
Dominic
Read The Docs? http://msdn.microsoft.com/scripting
Quote: > Thanks Dominic, > BTW I think you're right about using the Java class. I haven't had a
> chance to look at it properly yet - I've been avoiding Java of late, but
> you make a good point about the network file access.
> I wonder how they made this new XMLHTTP work? Do they use WinInet again,
> and if so how did they get round the inherent WinInet APIs being of a
> client nature? Does this mean the WinInet API has also been updated, or
> have they just managed to use it in a more server orientated way?
> > From the documentation:
> > The HTTP client stack offers longer uptimes. WinInet features that are
not
> > critical for server applications, such as URL caching, auto-discovery of
> > proxy servers, HTTP/1.1 chunking, offline support, and support for
gopher
> > and FTP protocols are not included in the new HTTP subset.
> > <
> > --
> > Dominic
> > Read The Docs? http://msdn.microsoft.com/scripting
> > > Hi,
> > > This sounds really cool. Do you know if it supports downloading large
> > > zip files using chunking?
> > > > Also check out the MSXML2.ServerXMLHTTP object which MS developed
> > > > specifically for server-side and not client-side use. It functions
the
> > same
> > > > as MSXML2.XMLHTTP.
> > > > --Ryan
> > > > ______________
> > > > This is madness!!!
> > > > > The problems of using Microsoft.XMLHTTP inside the ASP environment
are
> > > > > resolved in the beta version of MSXML2.
> > > > > The new progid of this object is MSXML2.XMLHTTP. It is used the
same
> > way
> > > > as
> > > > > the old Microsoft.XMLHTTP.
> > > > > You can get the beta from http://msdn.microsoft.com/xml.
> > > > > --
> > > > > Dominic
> > > > > Read The Docs? http://msdn.microsoft.com/scripting
> > > --
> > > Gerry Hickman (London UK)
> --
> Gerry Hickman (London UK)
|
| Wed, 16 Apr 2003 07:02:45 GMT |
|
|
|
Ryan N
#8 / 18
|
ANN: XMLHTTP In ASP Perhaps I am misunderstanding the need here but the ServerXMLHTTP object does not use WinInet: FROM THE XMLSDK30.CHM
{
ServerXMLHTTP Object
[This is preliminary documentation and subject to change.]
The ServerXMLHTTP object provides methods and properties that enable you to
establish an HTTP connection between files or objects on different Web
servers. For example, with ServerXMLHTTP, an Active Server Page (ASP),
Microsoft? Visual Basic?, or C++ component on a server computer can send an
HTTP request to another server and then receive the response as a stream or
XML document object. The response can then be fed to downstream clients,
saved to a file on the server, or combined with other XML data (potentially
collected from other Web servers).
ServerXMLHTTP offers other benefits for transporting XML data.
a.. ServerXMLHTTP maintains state, so it can be used in business
applications that require real-time responses.
b.. ServerXMLHTTP allows you to serve the response object as a stream or
Document Object Model (DOM) object. As a stream, the ServerXMLHTTP object
offers considerable performance benefits when moving data through the HTTP
protocol.
The ServerXMLHTTP component offers backward compatibility with XMLHTTP;
source code (Microsoft JScript?, Visual Basic Scripting Edition, Visual
Basic, or C++) that uses the XMLHTTP component can be easily modified to use
the new ServerXMLHTTP component.
Unlike XMLHTTP, the ServerXMLHTTP object does not rely on WinInet for HTTP.
ServerXMLHTTP uses a new HTTP client stack. Designed for server
applications, this "server-safe" subset of WinInet offers the following
advantages.
reliability
The HTTP client stack offers longer uptimes. WinInet features that are not
critical for server applications, such as URL caching, auto-discovery of
proxy servers, HTTP/1.1 chunking, offline support, and support for gopher
and FTP protocols are not included in the new HTTP subset.
security
The HTTP client stack enforces that a user-specific state cannot be shared
with another user's session.
The maximum number of ServerXMLHTTP instances that can exist simultaneously
within a single process is 5,460. A similar limitation applies to the
XMLHTTP component. However, other factors, such as available memory, CPU
processing capacity, or available socket connections can further limit the
number of ServerXMLHTTP instances that can be active simultaneously.
Partition the server application into multiple processes if this limit
becomes a bottleneck.
Quote: }
Quote: > Its still WinInet underneath, I don't think they have done anything with
it
> other than cut out some of the features. Resume is a problem in a lot of
> programming areas it seems. For example the MFC doens't have a clear way
of
> being able to perform resumed downloads.
> UPD: Java Class for Networking
> It would be very simple. Sun provides everything a networking related
> programmer could want. Except an easy way to resume a download. Firstly
the
> is the URL class, very easy to use for one chunk downloading but it comes
> unstuck if you try and use it for chunking. What should have been done is
> that the SkipBytes method (seek to a position in a byte stream) should
have
> been overridden from the foundation class DataInputStream. This would mean
> that it would behind the scenes to the skipping using the FTP protocol and
> everything would work great. However this is not the case, instead it
blocks
> all received data until it gets to the specified location, so this is not
> really resume.
> Sun also provides some excellent packages for working with all sorts of
> protocols (ftp, http, smtp, pop3, nntp, imap, gopher ...) However these
are:
> 1.] Not supported by Sun and prohibited for use in products (na)
> 2.] Not part of the MS JVM and therefore useless.
> The second point makes all these not worth knowing about.
> I am think now that perhaps a better way of doing it would be for me to
> create a java class that was instead executed via the command line. Or
more
> likely that I drop the Java idea and use a Winsock control.
> --
> Dominic
> Read The Docs? http://msdn.microsoft.com/scripting
> > Thanks Dominic,
> > BTW I think you're right about using the Java class. I haven't had a
> > chance to look at it properly yet - I've been avoiding Java of late, but
> > you make a good point about the network file access.
> > I wonder how they made this new XMLHTTP work? Do they use WinInet again,
> > and if so how did they get round the inherent WinInet APIs being of a
> > client nature? Does this mean the WinInet API has also been updated, or
> > have they just managed to use it in a more server orientated way?
> > > From the documentation:
> > > The HTTP client stack offers longer uptimes. WinInet features that are
> not
> > > critical for server applications, such as URL caching, auto-discovery
of
> > > proxy servers, HTTP/1.1 chunking, offline support, and support for
> gopher
> > > and FTP protocols are not included in the new HTTP subset.
> > > <
> > > --
> > > Dominic
> > > Read The Docs? http://msdn.microsoft.com/scripting
> > > > Hi,
> > > > This sounds really cool. Do you know if it supports downloading
large
> > > > zip files using chunking?
> > > > > Also check out the MSXML2.ServerXMLHTTP object which MS developed
> > > > > specifically for server-side and not client-side use. It functions
> the
> > > same
> > > > > as MSXML2.XMLHTTP.
> > > > > --Ryan
> > > > > ______________
> > > > > This is madness!!!
> > > > > > The problems of using Microsoft.XMLHTTP inside the ASP
environment
> are
> > > > > > resolved in the beta version of MSXML2.
> > > > > > The new progid of this object is MSXML2.XMLHTTP. It is used the
> same
> > > way
> > > > > as
> > > > > > the old Microsoft.XMLHTTP.
> > > > > > You can get the beta from http://msdn.microsoft.com/xml.
> > > > > > --
> > > > > > Dominic
> > > > > > Read The Docs? http://msdn.microsoft.com/scripting
> > > > --
> > > > Gerry Hickman (London UK)
> > --
> > Gerry Hickman (London UK)
|
| Wed, 16 Apr 2003 07:49:06 GMT |
|
|
|
Gerry Hickma
#9 / 18
|
ANN: XMLHTTP In ASP Hi Dominic, I was obviously asleep when I read your original post. I read it as
"HTTP 1.1 chunking is supported", whereas it now appears to say "not"
supported :)
I've been reading the beta SDK this afternoon. The server side HTTP
certainly does look interesting.
I'm not too worried about "resuming downloads" as such, but I definately
need status reporting and error reporting if the server goes down during
the download. For example if I want to schedule a large zip download for
midnight, I'd want to log file to record how far it got and why it
failed. As far as I know this can only be done with chunking, otherwise
the HTTP request will just download the whole zip file in one go with no
progress reporting. Maybe a timeout would work? I also may need a GUI
version at some point and again I'd want the user informed of how much
of the file had arrived.
The second part of the problem is saving the file to disk. The 8209
trick is very cool, but have you tested it on large files? I found the
conversion functions that need to be applied to the byte stream are
completely overloading the CPU and taking far too long. I notice in the
XML beta SDK there is a "save" method for saving XML documents to disk.
Do you know if this could be used to save a zip file?
Quote:
> Its still WinInet underneath, I don't think they have done anything with it
> other than cut out some of the features. Resume is a problem in a lot of
> programming areas it seems. For example the MFC doens't have a clear way of
> being able to perform resumed downloads.
> UPD: Java Class for Networking
> It would be very simple. Sun provides everything a networking related
> programmer could want. Except an easy way to resume a download. Firstly the
> is the URL class, very easy to use for one chunk downloading but it comes
> unstuck if you try and use it for chunking. What should have been done is
> that the SkipBytes method (seek to a position in a byte stream) should have
> been overridden from the foundation class DataInputStream. This would mean
> that it would behind the scenes to the skipping using the FTP protocol and
> everything would work great. However this is not the case, instead it blocks
> all received data until it gets to the specified location, so this is not
> really resume.
> Sun also provides some excellent packages for working with all sorts of
> protocols (ftp, http, smtp, pop3, nntp, imap, gopher ...) However these are:
> 1.] Not supported by Sun and prohibited for use in products (na)
> 2.] Not part of the MS JVM and therefore useless.
> The second point makes all these not worth knowing about.
> I am think now that perhaps a better way of doing it would be for me to
> create a java class that was instead executed via the command line. Or more
> likely that I drop the Java idea and use a Winsock control.
> --
> Dominic
> Read The Docs? http://msdn.microsoft.com/scripting
> > Thanks Dominic,
> > BTW I think you're right about using the Java class. I haven't had a
> > chance to look at it properly yet - I've been avoiding Java of late, but
> > you make a good point about the network file access.
> > I wonder how they made this new XMLHTTP work? Do they use WinInet again,
> > and if so how did they get round the inherent WinInet APIs being of a
> > client nature? Does this mean the WinInet API has also been updated, or
> > have they just managed to use it in a more server orientated way?
> > > From the documentation:
> > > The HTTP client stack offers longer uptimes. WinInet features that are
> not
> > > critical for server applications, such as URL caching, auto-discovery of
> > > proxy servers, HTTP/1.1 chunking, offline support, and support for
> gopher
> > > and FTP protocols are not included in the new HTTP subset.
> > > <
> > > --
> > > Dominic
> > > Read The Docs? http://msdn.microsoft.com/scripting
> > > > Hi,
> > > > This sounds really cool. Do you know if it supports downloading large
> > > > zip files using chunking?
> > > > > Also check out the MSXML2.ServerXMLHTTP object which MS developed
> > > > > specifically for server-side and not client-side use. It functions
> the
> > > same
> > > > > as MSXML2.XMLHTTP.
> > > > > --Ryan
> > > > > ______________
> > > > > This is madness!!!
> > > > > > The problems of using Microsoft.XMLHTTP inside the ASP environment
> are
> > > > > > resolved in the beta version of MSXML2.
> > > > > > The new progid of this object is MSXML2.XMLHTTP. It is used the
> same
> > > way
> > > > > as
> > > > > > the old Microsoft.XMLHTTP.
> > > > > > You can get the beta from http://msdn.microsoft.com/xml.
> > > > > > --
> > > > > > Dominic
> > > > > > Read The Docs? http://msdn.microsoft.com/scripting
> > > > --
> > > > Gerry Hickman (London UK)
> > --
> > Gerry Hickman (London UK)
-- Gerry Hickman (London UK)
|
| Thu, 17 Apr 2003 01:07:46 GMT |
|
|
|
Michael Harri
#10 / 18
|
ANN: XMLHTTP In ASP <snip>
Quote: > The second part of the problem is saving the file to disk. The 8209
> trick is very cool, but have you tested it on large files? I found the
> conversion functions that need to be applied to the byte stream are
> completely overloading the CPU and taking far too long. I notice in the
<snip> Here's a *much* faster technique using an ADODB.Stream object. This is a script that Tom Lavedas
posted originally used the Chr(AscB(MidB(...))) technique. I adapted it to use an ADODB.Stream
object. The example is hardcode to download a JPEG from the MSDN scripting site, but the technique
would work for any binary file accessible via an http URL. The timer() business is just for crude
benchmarking.
===========================================
'<job ID="GetHTTP"><script language="VBScript">
' Adapted slightly by Tom Lavedas to speed it up a bit
' June 2000
'----------------
'Further adapted by Michael Harris to use an ADODB.Stream...
'----------------
' HTTP download w/o zUI.
' 3/10/2K
'
' This script demonstrates how to download a file from
' the web, using Microsoft.XMLHTTP to retrieve the file
' and FileSystemObject for **binary** file output.
'
' Script concept was introduced by Eric K.
' Michael Harris revealed to us the secrets of the
' VBScript type 8209 byte array.
' LiL Endian found the elegant function combination to
' convert binary byte data into a string FSO could
' output correctly.
'----------------
'--Begin user variables--
sSource = "http://msdn.microsoft.com/scripting/art/t_scripting.jpg"
sDest = "test.jpg"
'---End user variables---
set oHTTP = WScript.CreateObject("Microsoft.XMLHTTP")
oHTTP.open "GET", sSource, False
oHTTP.send
tStart = timer()
set oStream = createobject("adodb.stream")
Const adTypeBinary = 1
Const adSaveCreateNotExist = 1
Const adSaveCreateOverWrite = 2
oStream.type = adTypeBinary
oStream.open
oStream.write oHTTP.responseBody
oStream.savetofile sDest, adSaveCreateOverWrite
set oStream = nothing
tElapsed = timer() - tStart
set oHTTP = nothing
WScript.Echo "Done! " & tElapsed & " seconds..."
'</script></job>
--
Michael Harris
Microsoft.MVP.Scripting
--
|
| Thu, 17 Apr 2003 01:48:09 GMT |
|
|
|
Gerry Hickma
#11 / 18
|
ANN: XMLHTTP In ASP Hi Michael,
Quote: > Here's a *much* faster technique using an ADODB.Stream object. This is a script that Tom Lavedas
> posted originally used the Chr(AscB(MidB(...))) technique. I adapted it to use an ADODB.Stream
> object.
EXCELLENT WORK! This is very nice, and I imgine it will also now easily port to JScript.
It doesn't solve the chunking issue and status reporting, but it's a
massive step forward from the 8209.
I had to update my MDAC to use it, and chose 2.5 as it appears 2.6 does
not contain JET (which we still use from time to time).
--
Gerry Hickman (London UK)
|
| Fri, 18 Apr 2003 03:51:02 GMT |
|
|
|
Manfred Brau
#12 / 18
|
ANN: XMLHTTP In ASP Hello Michael and All,
nice work, good idea to use ADO! But, while it seems to work for others, so
not for me :-(
I have to do it over proxy and the proxy told me, I passed an invalid http
request!! Are there out others, facing that problem?? If I pass the url via
my browser, I get the image!
Thanks
and best regards,
Manfred Braun
(Private)
Lange Roetterstrasse 7
D68167 Mannheim
Germany
(Remove the anti-spam-underscore to mail me!)
Quote: > <snip> > > The second part of the problem is saving the file to disk. The 8209
> > trick is very cool, but have you tested it on large files? I found the
> > conversion functions that need to be applied to the byte stream are
> > completely overloading the CPU and taking far too long. I notice in the
> <snip>
> Here's a *much* faster technique using an ADODB.Stream object. This is a
script that Tom Lavedas Quote: > posted originally used the Chr(AscB(MidB(...))) technique. I adapted it
to use an ADODB.Stream Quote: > object. The example is hardcode to download a JPEG from the MSDN
scripting site, but the technique Quote: > would work for any binary file accessible via an http URL. The timer()
business is just for crude Quote: > benchmarking. > ===========================================
> '<job ID="GetHTTP"><script language="VBScript">
> ' Adapted slightly by Tom Lavedas to speed it up a bit
> ' June 2000
> '----------------
> 'Further adapted by Michael Harris to use an ADODB.Stream...
> '----------------
> ' HTTP download w/o zUI.
> ' 3/10/2K
> '
> ' This script demonstrates how to download a file from
> ' the web, using Microsoft.XMLHTTP to retrieve the file
> ' and FileSystemObject for **binary** file output.
> '
> ' Script concept was introduced by Eric K.
> ' Michael Harris revealed to us the secrets of the
> ' VBScript type 8209 byte array.
> ' LiL Endian found the elegant function combination to
> ' convert binary byte data into a string FSO could
> ' output correctly.
> '----------------
> '--Begin user variables--
> sSource = "http://msdn.microsoft.com/scripting/art/t_scripting.jpg"
> sDest = "test.jpg"
> '---End user variables---
> set oHTTP = WScript.CreateObject("Microsoft.XMLHTTP")
> oHTTP.open "GET", sSource, False
> oHTTP.send
> tStart = timer()
> set oStream = createobject("adodb.stream")
> Const adTypeBinary = 1
> Const adSaveCreateNotExist = 1
> Const adSaveCreateOverWrite = 2
> oStream.type = adTypeBinary
> oStream.open
> oStream.write oHTTP.responseBody
> oStream.savetofile sDest, adSaveCreateOverWrite
> set oStream = nothing
> tElapsed = timer() - tStart
> set oHTTP = nothing
> WScript.Echo "Done! " & tElapsed & " seconds..."
> '</script></job>
> --
> Michael Harris
> Microsoft.MVP.Scripting
> --
|
| Sat, 19 Apr 2003 04:19:45 GMT |
|
|
|
Gerry Hickma
#13 / 18
|
ANN: XMLHTTP In ASP Hi Manfred, There's a proxy config file (and associated text) as part of the new XML
beta, so it might be worth a look. Alternatively, check the proxy server
logs and try to determine what's causing the error. Could be something
to do with underlying protocols...
Quote:
> Hello Michael and All,
> nice work, good idea to use ADO! But, while it seems to work for others, so
> not for me :-(
> I have to do it over proxy and the proxy told me, I passed an invalid http
> request!! Are there out others, facing that problem?? If I pass the url via
> my browser, I get the image!
> Thanks
> and best regards,
> Manfred Braun
> (Private)
> Lange Roetterstrasse 7
> D68167 Mannheim
> Germany
> (Remove the anti-spam-underscore to mail me!)
> > <snip>
> > > The second part of the problem is saving the file to disk. The 8209
> > > trick is very cool, but have you tested it on large files? I found the
> > > conversion functions that need to be applied to the byte stream are
> > > completely overloading the CPU and taking far too long. I notice in the
> > <snip>
> > Here's a *much* faster technique using an ADODB.Stream object. This is a
> script that Tom Lavedas
> > posted originally used the Chr(AscB(MidB(...))) technique. I adapted it
> to use an ADODB.Stream
> > object. The example is hardcode to download a JPEG from the MSDN
> scripting site, but the technique
> > would work for any binary file accessible via an http URL. The timer()
> business is just for crude
> > benchmarking.
> > ===========================================
> > '<job ID="GetHTTP"><script language="VBScript">
> > ' Adapted slightly by Tom Lavedas to speed it up a bit
> > ' June 2000
> > '----------------
> > 'Further adapted by Michael Harris to use an ADODB.Stream...
> > '----------------
> > ' HTTP download w/o zUI.
> > ' 3/10/2K
> > '
> > ' This script demonstrates how to download a file from
> > ' the web, using Microsoft.XMLHTTP to retrieve the file
> > ' and FileSystemObject for **binary** file output.
> > '
> > ' Script concept was introduced by Eric K.
> > ' Michael Harris revealed to us the secrets of the
> > ' VBScript type 8209 byte array.
> > ' LiL Endian found the elegant function combination to
> > ' convert binary byte data into a string FSO could
> > ' output correctly.
> > '----------------
> > '--Begin user variables--
> > sSource = "http://msdn.microsoft.com/scripting/art/t_scripting.jpg"
> > sDest = "test.jpg"
> > '---End user variables---
> > set oHTTP = WScript.CreateObject("Microsoft.XMLHTTP")
> > oHTTP.open "GET", sSource, False
> > oHTTP.send
> > tStart = timer()
> > set oStream = createobject("adodb.stream")
> > Const adTypeBinary = 1
> > Const adSaveCreateNotExist = 1
> > Const adSaveCreateOverWrite = 2
> > oStream.type = adTypeBinary
> > oStream.open
> > oStream.write oHTTP.responseBody
> > oStream.savetofile sDest, adSaveCreateOverWrite
> > set oStream = nothing
> > tElapsed = timer() - tStart
> > set oHTTP = nothing
> > WScript.Echo "Done! " & tElapsed & " seconds..."
> > '</script></job>
> > --
> > Michael Harris
> > Microsoft.MVP.Scripting
> > --
-- Gerry Hickman (London UK)
|
| Sat, 19 Apr 2003 04:31:05 GMT |
|
|
|
Manfred Brau
#14 / 18
|
ANN: XMLHTTP In ASP Hi Gerry, fast, fast, ... ;-)
Thanks for your reply. The proxy displays the error as "invalid" request and
list possible reasons, but I cannot see them there :-( [possibly, I am
blind]
I did my try with the "old" component.....so looking for the settings file
is currently worthless; Thought, the ADO trick itself should work even with
the old component.
The problem, so far I can see, lies in the component. I use it regularly
and was faces several times with the error:
HTTP_STATUS_LENGTH_REQUIRED 411 The server refuses to accept the request
without a defined content length.
(Copies from the MSDN ref). I tried my header-fetch sample with the URL from
Michaels sample and got the sam error. I saw that error several times using
the old component. So I have still to wait for the new one.....
Thanks a lot,
Manfred
Quote: > Hi Manfred, > There's a proxy config file (and associated text) as part of the new XML
> beta, so it might be worth a look. Alternatively, check the proxy server
> logs and try to determine what's causing the error. Could be something
> to do with underlying protocols...
> > Hello Michael and All,
> > nice work, good idea to use ADO! But, while it seems to work for
others, so
> > not for me :-(
> > I have to do it over proxy and the proxy told me, I passed an invalid
http
> > request!! Are there out others, facing that problem?? If I pass the url
via
> > my browser, I get the image!
> > Thanks
> > and best regards,
> > Manfred Braun
> > (Private)
> > Lange Roetterstrasse 7
> > D68167 Mannheim
> > Germany
> > (Remove the anti-spam-underscore to mail me!)
> > > <snip>
> > > > The second part of the problem is saving the file to disk. The 8209
> > > > trick is very cool, but have you tested it on large files? I found
the
> > > > conversion functions that need to be applied to the byte stream are
> > > > completely overloading the CPU and taking far too long. I notice in
the
> > > <snip>
> > > Here's a *much* faster technique using an ADODB.Stream object. This
is a
> > script that Tom Lavedas
> > > posted originally used the Chr(AscB(MidB(...))) technique. I adapted
it
> > to use an ADODB.Stream
> > > object. The example is hardcode to download a JPEG from the MSDN
> > scripting site, but the technique
> > > would work for any binary file accessible via an http URL. The
timer()
> > business is just for crude
> > > benchmarking.
> > > ===========================================
> > > '<job ID="GetHTTP"><script language="VBScript">
> > > ' Adapted slightly by Tom Lavedas to speed it up a bit
> > > ' June 2000
> > > '----------------
> > > 'Further adapted by Michael Harris to use an ADODB.Stream...
> > > '----------------
> > > ' HTTP download w/o zUI.
> > > ' 3/10/2K
> > > '
> > > ' This script demonstrates how to download a file from
> > > ' the web, using Microsoft.XMLHTTP to retrieve the file
> > > ' and FileSystemObject for **binary** file output.
> > > '
> > > ' Script concept was introduced by Eric K.
> > > ' Michael Harris revealed to us the secrets of the
> > > ' VBScript type 8209 byte array.
> > > ' LiL Endian found the elegant function combination to
> > > ' convert binary byte data into a string FSO could
> > > ' output correctly.
> > > '----------------
> > > '--Begin user variables--
> > > sSource = "http://msdn.microsoft.com/scripting/art/t_scripting.jpg"
> > > sDest = "test.jpg"
> > > '---End user variables---
> > > set oHTTP = WScript.CreateObject("Microsoft.XMLHTTP")
> > > oHTTP.open "GET", sSource, False
> > > oHTTP.send
> > > tStart = timer()
> > > set oStream = createobject("adodb.stream")
> > > Const adTypeBinary = 1
> > > Const adSaveCreateNotExist = 1
> > > Const adSaveCreateOverWrite = 2
> > > oStream.type = adTypeBinary
> > > oStream.open
> > > oStream.write oHTTP.responseBody
> > > oStream.savetofile sDest, adSaveCreateOverWrite
> > > set oStream = nothing
> > > tElapsed = timer() - tStart
> > > set oHTTP = nothing
> > > WScript.Echo "Done! " & tElapsed & " seconds..."
> > > '</script></job>
> > > --
> > > Michael Harris
> > > Microsoft.MVP.Scripting
> > > --
> --
> Gerry Hickman (London UK)
|
| Sat, 19 Apr 2003 05:24:22 GMT |
|
|
|
Gerry Hickma
#15 / 18
|
ANN: XMLHTTP In ASP Hi, Quote: > I did my try with the "old" component.....so looking for the settings file
> is currently worthless;
But the info in the beta may be relevant to proxies? I've never used a proxy so I don't really know the answer. Quote: > HTTP_STATUS_LENGTH_REQUIRED 411 The server refuses to accept the request
> without a defined content length.
The component is supposed to set the length automatically. Not sure why it woudn't work with the proxy. Do you have the docs for the proxy? --
Gerry Hickman (London UK)
|
| Sat, 19 Apr 2003 08:00:30 GMT |
|
| |
Page 1 of 2
|
[ 18 post ] |
|
Go to page:
[1]
[2] |
|
