MinGW - Minimalist GNU for Windows / Issues / #1592 mingw-get.exe: unexpected status: code = 304

Keith Marshall - 2011-11-24

I can confirm that missing flex leads to the failure you reported on the ML, and below. I've opened a new ticket to address the issue; see:
https://sourceforge.net/tracker/?func=detail&aid=3441809&group_id=2435&atid=102435

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Robert Hartmann - 2011-12-06

Hi Keith,

I havn't forgot my promise, to help with debugging.
I thought about some test cases. For that I am now programming a "small" IE 6 Cache Editor (Win XP), so that I am able to simulate some situations.

Best regards,
Robert

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Robert Hartmann - 2017-03-31
  
  Hi Keith,
  I did not forgot my promise. Programming this "small" IE 6 Cache Editor for becoming able to
  simulate some Network-messages or manipulating existent IEcache-Entries took (and takes up
  to now) much more time, than I thought about 5 years ago.
  My Editor can search for or delete IE-cache entries.
  As soon as my editor can insert and update entries with fake information I am well prepared for
  doing more analyse.
  Best regards,
  Robert
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Earnie Boyd - 2013-01-21

resolution: --> none

category: --> Waiting_User_Response

milestone: Waiting_User_Response --> INSTALLER
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Earnie Boyd - 2013-02-08

labels: mingw-get -->

type: --> Bug

patch_attached: --> False
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sebastian Schuberth - 2013-04-10

Any progress update on this issue? I'm seeing it, too, when I'm behind a proxy server. Seems like there's bug in mingw-get to retrieve contents from IE's local cache when HTTP status code 304 is received from the proxy server.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Earnie Boyd - 2013-04-10
  
  Sebastian, have you tried the alpha candidate? You can find it at https://sourceforge.net/projects/keithmarshall.u/files/mingw-get/ to give it a try.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Keith Marshall - 2013-04-10
  
  Well, I contend that the bug lies within Microsoft's wininet.dll, and not within mingw-get.exe; if wininet.dll is going to, by default, insist on looking for existing cached content, (by gratuitous interposition of If-Modified-Since headers into my InternetOpenUrl requests), then it should also transparently, and by default, satisfy my InternetReadFile requests from said cache; it should not force me to run around in circles, cleaning up after its gross ineptitude. That said, perhaps mingw-get.exe could be more proactive in handling the situation.
  
  I do wonder why, in all the time mingw-get.exe has been "out in the wild", only two users worldwide seem to be afflicted by this issue. I am not, so it is difficult for me to effectively test possible solutions. I did offer a tentative patch, (attached to this ticket), but there has been no further action, pending testing by the OP, or another user who does experience the issue; (I see little advantage in applying a patch without confirmation that it does provide an effective solution).
  
  Beyond this, I am willing to consider patches, but I wonder if a simpler solution may not be to add any, or all of:--
  
  INTERNET_FLAG_RELOAD, INTERNET_FLAG_PRAGMA_NOCACHE, INTERNET_FLAG_NO_CACHE_WRITE, and (unrelated, but maybe also useful) INTERNET_FLAG_KEEP_CONNECTION.
  
  to the attributes specified for the InternetOpenUrl() request. However, without feedback from affected users, this issue isn't likely to be resolved any time soon.
  
  Last edit: Keith Marshall 2013-04-10
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Keith Marshall - 2013-04-10

Patch attached: False --> True
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sebastian Schuberth - 2013-04-22

Sorry for the late response. Unfortunately, I'm unable to reliably reproduce the issue. However, I managed to reproduce it once from my home PC which is not behind a proxy. But I got the 304 error only for my own custom packages that are hosted on my Dropbox account; other upstream packages hosted on SF were downloaded just fine. So Dropbox probably also implements some proxy-like tricks to avoid transferring files again.

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
- Earnie Boyd - 2013-04-22
  
  Why are you using Dropbox for your custom packages? You have a SF account, so use the tools under http://sf.net/u/eyebex instead for your custom packages. I really dislike Dropbox.
  
  If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

Sebastian Schuberth - 2013-04-22

Because I in turn started to dislike SF. It has become incredibly slow over the years, and the UI is way to wasteful on screen space. Also, SF has not defined contribution workflow (like GitHub's pull requests, for example). And so on.

Dropbox is just convenient to use while I'm still testing my packages. I'm planning to host them on Bintray [1] when I'm ready.

But I guess this is all off-topic. mingw-get should work just fine nonetheless.

[1] https://bintray.com/repo/browse/sschuberth/mingwGitDevEnv

If you would like to refer to this comment somewhere else in this project, copy and paste the following link:

mingw-get.exe: unexpected status: code = 304

A native Windows port of the GNU Compiler Collection (GCC)

Group

Searches

Help

#1592 mingw-get.exe: unexpected status: code = 304

Discussion