Commit Graph

13 Commits

Author SHA1 Message Date
Philip Withnall
562ac9de43 gwinhttpvfs: Fall back to wrapped VFS if creating a HTTP file fails
If we fail to create a GWinhttpFile for a URI (for example, because it’s
an invalid URI or is badly encoded), don’t just return NULL. Instead,
fall back to the wrapped VFS which might be able to handle it instead.

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #1819
2019-08-27 08:21:26 +03:00
Руслан Ижбулатов
ccbadcfb04 GWinHTTPVfs: use URI parser for parsing URIs
If a URI can't be handled by by WinHTTPVfs, it should pass that URI
along to the URI parser of the wrapped Vfs, not to its generic parser.
Theoretically, generic parser should also be able to handle URIs,
but this is subject to Vfs semantics.

In case of Windows, the wrapped Vfs is GLocalVfs, which is *local* and
treats any generic names as either file:// URIs or as filesystem
paths. It only ever treats URIs as URIs when they are passed
to its URI parser. This breaks the testsuite when g-icon GIO test passes
unhandleable sftp:// URI, and expects it to come through unmolested,
yet GLocalVfs, getting that URI as a generic parse name, treats it as
a filesystem path, and then "canonicalizes" it by prepending CWD.

Fix this by making WinHTTPVfs pass any URIs it gets to the URI parser
of the wrapped Vfs. This way unknown URIs remain URI-ish. This seems
like a reasonable things to do, since the URI parser should not be
given anything other than URIs, so there's no reason to try generic
parsing with these strings.

Closes: #875
2019-02-13 08:49:42 +00:00
Sébastien Wilmet
408381b8ae gio/win32/: LGPLv2+ -> LGPLv2.1+
https://bugzilla.gnome.org/show_bug.cgi?id=776504
2017-05-29 19:53:34 +02:00
Rico Tzschichholz
e0e52b60ea docs: Fix broken gtk-doc formatting 2014-08-18 14:08:41 +02:00
Daniel Mustieles
078dbda148 Updated FSF's address 2014-01-31 14:31:55 +01:00
Matthias Clasen
4e55bebb7a Fix leak in GWinHttpVfs
Patch by Ole André Vadla Ravnås, bug
https://bugzilla.gnome.org/show_bug.cgi?id=627423
2012-08-16 22:17:46 -04:00
Tor Lillqvist
6ddef375c8 Recuce DLL hijack risk on Windows
Don't call LoadLibrary() on shell32.dll or kernel32.dll. kernel32.dll
is always loaded. Shell32.dll is also already loaded as glib links to
functions in it. So just call GetModuleHandle() on them.

For mlang.dll in win_iconv.c and winhttp.dll in gwinhttpvfs.c, always
try loading them from a complete path, from the Windows system
directory.

Use the "tool help" API to enumerate modules in gmodule-win32.c. It is
present in all Windows versions since Windows 2000, which is all we
support anyway. Thus no need to look that API up dynamically. Just
link to it normally. We can bin the fallback code that attempts to use
the psapi API.
2010-09-02 22:36:47 +03:00
Tor Lillqvist
398f9841ed Fix gio/win32 build after -I flag changes 2010-08-10 16:01:39 +03:00
Ryan Lortie
5b946e0504 gio/: fully remove gioalias hacks 2010-07-07 19:53:22 -04:00
Matthias Clasen
8907bfee86 Fix up GIO docs 2009-11-29 22:54:16 -05:00
Tor Lillqvist
2f575b95ac Bug 556415 - Crash on Windows 2000 in g_winhttp_vfs_init()
2008-11-12  Tor Lillqvist  <tml@novell.com>

	Bug 556415 - Crash on Windows 2000 in g_winhttp_vfs_init()

	* win32/gwinhttpvfs.h: Move the set of function pointers to
	winhttp.dll into a separate struct GWinHttpDllFuncs. Just have a
	pointer to that in the GWinHttpVfsClass.
	
	* win32/gwinhttpvfs.c: Move the lookup of functions from
	winhttp.dll into a function of its own, that stores the pointers
	in a separate GWinHttpDllFuncs variable. Add two bookeeping
	booleans lookup_done and funcs_found.

	Don't call g_io_extension_point_implement() to register the
	winhttp extension unless winhttp.dll has been successfully loaded
	and the required functions found in it.

	* win32/gwinhttp*.c: Adjust calls of the functions looked up from
	winhttp.dll correspondingly.


svn path=/trunk/; revision=7648
2008-11-12 17:52:39 +00:00
Tor Lillqvist
d5863830ad win32/gwinhttpvfs.c win32/gwinhttpvfs.h win32/gwinhttpfile.c
2008-08-13  Tor Lillqvist  <tml@novell.com>

	* win32/gwinhttpvfs.c
	* win32/gwinhttpvfs.h
	* win32/gwinhttpfile.c
	* win32/gwinhttpfileinputstream.c
	* win32/gwinhttpfileoutputstream.c: Refactor some common code
	snippets into helper functions. Check HTTP response status
	codes. Implement g_winhttp_file_query_info(), looking at
	Content-Length, Content-Type and Last-Modified.

	* win32/winhttp.h: Add some symbolic constants that are not
	publicly documented. Just a handful, so it should be OK to use
	information from the Windows SDK's headers.


svn path=/trunk/; revision=7350
2008-08-13 19:39:49 +00:00
Tor Lillqvist
7261372b45 win32/gwinhttpvfs.c win32/gwinhttpvfs.h win32/gwinhttpfile.c
2008-08-13  Tor Lillqvist  <tml@novell.com>

	* win32/gwinhttpvfs.c
	* win32/gwinhttpvfs.h
	* win32/gwinhttpfile.c
	* win32/gwinhttpfile.h
	* win32/gwinhttpfileinputstream.c
	* win32/gwinhttpfileinputstream.h
	* win32/gwinhttpfileoutputstream.c
	* win32/gwinhttpfileoutputstream.h: New files implementing
	GWinHttpVfs and related classes, a GVfs for HTTP and HTTPS URIs on
	Windows. The implementation uses the WinHttp API. Both reading and
	writing are supported, i.e. GET and PUT requests. When writing,
	each write call is done using a separate PUT request with a
	Content-Range header. Requests for file URIs and plain pathnames
	are forwarded to GLocalVfs.

	* win32/winhttp.h: Reverse engineered <winhttp.h>, borrowed from
	WINE. Used as there is no <winhttp.h> bundled with mingw, and
	requiring people to download the Windows SDK just for this one
	header is not reasonable.

	* win32/Makefile.am: Add above files.

	* giomodule.c: Call _g_winhttp_vfs_get_type() on Windows to set up
	the plumbing for the above.


svn path=/trunk/; revision=7344
2008-08-12 23:09:04 +00:00