[bug #65978] no way to install Google Chrome which is requered to use French officials websites

Update of bug #65978 (group wget): Status:None => Invalid Assigned to:None => rockdaboot Open/Closed:Open => Closed

[bug #55087] Please add parsing of picture element sources to `wget -r`

Update of bug#55087 (group wget): Status:None => Fixed Assigned to:None => rockdaboot Open/Closed:Open => Closed Release:

[bug #64808] When I use wget to download some files from a web server, files with russian names do not get proper names

Follow-up Comment #6, bug#64808 (group wget): Ideally, you give us a command line example so we can reproduce. I can not resolve app.kali.by. ___ Reply to this item at:

[bug #65007] wget uses non-standard way to print IPv6 addresses

Follow-up Comment #1, bug#65007 (group wget): I get your point. The output line has the same format for IPv6 and IPv4 where the IP address representation and the port number are printed as two fields separated by `|:`. E.g. for an IPv4 address, the string is also not as "usually done":

[bug #64916] can't load Windows binary in Windows 11 Pro

Update of bug #64916 (project wget): Status:None => Invalid Open/Closed:Open => Closed ___ Reply to this item at:

[bug #64808] When I use wget to download some files from a web server, files with russian names do not get proper names

Follow-up Comment #4, bug #64808 (project wget): Windows character encodings may be special. Is this issue reproducible on e.g. GNU/Linux? I am willing to test it on GNU/Linux, but I need a full command line example from you. Out of curiosity, can you test wget2.exe from

[bug #64808] When I use wget to download some files from a web server, files with russian names do not get proper names

Follow-up Comment #1, bug #64808 (project wget): Did you test `--restrict-file-names` with different options ? If that doesn't help, there is also `--local-encoding` and `--remote-encoding` to experiment with. ___ Reply to this item at:

[bug #64710] wget for Linux

Update of bug #64710 (project wget): Status:None => Invalid Open/Closed:Open => Closed ___ Reply to this item at:

[bug #63563] wget --timeout=30 not working during suspend / resume

Update of bug #63563 (project wget): Status:None => Need Info Open/Closed:Open => Closed ___ Reply to this item at:

[bug #63431] --disable-ntlm ignored if nettle is present

Update of bug #63431 (project wget): Status:None => Fixed Assigned to:None => rockdaboot Open/Closed:Open => Closed Fixed Release:

[bug #62586] Warning given every time wget runs: “.netrc:..: unknown token” when a password contains quotes

Follow-up Comment #1, bug #62586 (project wget): As you mention, there is no standard/spec. And this puts this issue into an unsolvable state. Too many clients have their own, slightly diverting implementation. Whatever any client will change, it likely breaks backwards compatibility. I looked

[bug #62516] "--convert-links" converts frags unnecessarily

Update of bug #62516 (project wget): Status:None => Confirmed ___ Follow-up Comment #1: Can confirm that is is reproducible for latest wget (git). Just fyi, the same issue has been

[bug #61981] Option --retry-on-host-error is missing in the help command

Update of bug #61981 (project wget): Status:None => Fixed Assigned to:None => rockdaboot Open/Closed:Open => Closed Release:

[bug #62110] HSTS broken on 32 bit big endian devices

Update of bug #62110 (project wget): Status:None => Fixed Assigned to:None => rockdaboot Open/Closed:Open => Closed

[bug #62110] HSTS broken on 32 bit big endian devices

Follow-up Comment #13, bug #62110 (project wget): Created https://gitlab.com/gnuwget/wget/-/merge_requests/31 to address this issue. Can someone please provide feedback for 32 bit little and big endian ? ___ Reply to this item at:

[bug #62110] HSTS broken on 32 bit big endian devices

Follow-up Comment #12, bug #62110 (project wget): IMO, the problem is that the code uses a time_t variable and uses sscanf SCNd64. That means that time_t *must* be a 64bit integer (signed or unsigned doesn't matter), which is of course not always true. C99/C11 does not define a format specifier

[bug #61038] Windows post fails to post files over 65536 bytes,

Follow-up Comment #7, bug #61038 (project wget): On the first glimpse, https://github.com/rockdaboot/wget2/issues/256 is unrelated. But then it seems that the poll/select function on Windows sometimes reports "ready to read" but the next read returns 0 bytes read. (Wget2 used non-blocking I/O).

[bug #61755] --unlink doesn't

Update of bug #61755 (project wget): Status: Confirmed => Fixed Assigned to:None => rockdaboot Open/Closed:Open => Closed Fixed Release:

[bug #61755] --unlink doesn't

Follow-up Comment #3, bug #61755 (project wget): Fixed this for Wget2 now. I'll take a look at wget later. ___ Reply to this item at: ___ Message sent

[bug #61649] Wget not honouring Content-Encoding: gzip

Follow-up Comment #3, bug #61649 (project wget): Wget2 handles the cloudfront example correctly. And --no-compression means "do not send Accept-Encoding", while the Content-Encoding header is fully respected. --compression=none is the same as --compression=identity (send Accept-Encding:

[bug #61755] --unlink doesn't

Update of bug #61755 (project wget): Status:None => Confirmed ___ Follow-up Comment #1: Thanks, I confirm this issue is reproducible on latest wget and wget2.

[bug #61492] --no-verbose leaks information about HTTP password to stdout

Update of bug #61492 (project wget): Status:None => Confirmed ___ Reply to this item at: ___

[bug #61416] Manpage on --secure-protocol could be improved

Update of bug #61416 (project wget): Status:None => Confirmed ___ Follow-up Comment #1: You are right, the exact behavior needs to be clarified in the docs. > is there a way to force

[bug #61038] Windows post fails to post files over 65536 bytes,

Follow-up Comment #2, bug #61038 (project wget): Since this is a Windows issue, could you please report this issue to where you got the binary from ? Please feel free to update this issue with any information you get from there. ___

[bug #60956] stylesheet and icon elements not properly classified as page requisites

Update of bug #60956 (project wget): Status:None => Confirmed Assigned to:None => rockdaboot ___ Follow-up Comment #1: Thank you for the

[bug #60865] wget puts robots.txt and headers into the downloaded file --no-clobber -A without robots.txt

Update of bug #60865 (project wget): Status:None => Fixed Assigned to:None => rockdaboot Open/Closed:Open => Closed

[bug #60804] issue in French warning

Follow-up Comment #1, bug #60804 (project wget): Please address translation issues directly to the translation team at https://translationproject.org/team/fr.html Thank you ___ Reply to this item at:

[bug #60804] issue in French warning

Update of bug #60804 (project wget): Assigned to:None => rockdaboot Open/Closed:Open => Closed ___ Reply to this item at:

[bug #60494] Percent character in filename gets escaped twice

Follow-up Comment #8, bug #60494 (project wget): So what KodeCharlie says is correct (regarding b)). I would reword it like: We have arbitrary user input which has nothing to do what RFCs say. And this is the hard part as we have to 'guess' what the user meant. Once the input is 'normalized'

[bug #60494] Percent character in filename gets escaped twice

Follow-up Comment #5, bug #60494 (project wget): The main Q is how does Wget know if the input URL is already escaped or not ? Did you read this comment ? https://gitlab.com/gnuwget/wget/-/blob/master/src/url.c#L329 ___ Reply to this item

[bug #56909] wget Authorization header leak via 3xx redirects

Follow-up Comment #7, bug #56909 (project wget): The Authorization is not special when set manually (someone else may want to use a different header to send private information that should removed on redirection). So a new option may allow detailed control over how often each manually set header

[bug #60346] Failed to rename file to file.1: (17) File exists

Update of bug #60346 (project wget): Status:None => Needs Investigation Assigned to:None => rockdaboot ___ Follow-up Comment #2: Just realized that

[bug #60346] Failed to rename file to file.1: (17) File exists

Follow-up Comment #1, bug #60346 (project wget): Can you confirm that this failure happens also with an older version of wget (e.g. 1.20 or 1.19) ? The answer could help in tracking down the issue and to find a way to work around it. ___

[bug #60353] On 32-bit arm, wget is unable to download a file bigger than 2GiB

Update of bug #60353 (project wget): Status:None => Fixed Assigned to:None => rockdaboot Open/Closed:Open => Closed Regression:

[bug #60106] wget mistakenly interprets Content-Range as bytes and truncates content

Follow-up Comment #6, bug #60106 (project wget): I love to see that wget2 downloas the 4027 bytes and saves it as 'submission' ;-) ___ Reply to this item at:

[bug #60106] wget mistakenly interprets Content-Range as bytes and truncates content

Update of bug #60106 (project wget): Summary: wget mistakenly interprets Content-Range as bytes, even with Range-Unit: items, and truncates content => wget mistakenly interprets Content-Range as bytes and truncates content

[bug #60106] wget mistakenly interprets Content-Range as bytes, even with Range-Unit: items, and truncates content

Update of bug #60106 (project wget): Status: Invalid => Confirmed Open/Closed: Closed => Open ___ Follow-up Comment #5: Thanks for reporting

[bug #59954] wget assumes ftp server of type UNIX knows LIST -a command while this is not always true

Follow-up Comment #3, bug #59954 (project wget): So most servers either support -a or ignore it and still return a directory listing (tested your examples). > Maybe wget could fallback to LIST (without -a) when there is no parsed result in the output, too? I agree that this seems to be the most

[bug #59954] wget assumes ftp server of type UNIX knows LIST -a command while this is not always true

Update of bug #59954 (project wget): Status: Inspected => Confirmed ___ Reply to this item at: ___

[bug #59954] wget assumes ftp server of type UNIX knows LIST -a command while this is not always true

Update of bug #59954 (project wget): Status:None => Inspected Assigned to:None => rockdaboot ___ Follow-up Comment #1: Wget always tries

[bug #58050] Incorrect timeout handling when tls transport is registered

Follow-up Comment #3, bug #58050 (project wget): Fixed by https://git.savannah.gnu.org/cgit/wget.git/commit/?id=7a3a82faf86eab6c1f0c453de1923f8a1e0f4706 ___ Reply to this item at:

[bug #58050] Incorrect timeout handling when tls transport is registered

Update of bug #58050 (project wget): Status:None => Fixed Assigned to:None => rockdaboot Open/Closed:Open => Closed Fixed Release:

[bug #59363] wget with --wait (crawling specific domain's specific url with wait)

Follow-up Comment #1, bug #59363 (project wget): Not sure if I understand you correctly. You say that you expect --wait=N to wait N seconds *before* a retrieval !? The documentation is pretty clear saying *between* retrievals, not *before* and not *after*. In other words, the first retrieval

[bug #58354] Wget doesn't parse URIs starting with http:/

Update of bug #58354 (project wget): Status:None => Confirmed ___ Follow-up Comment #2: We could accept this while parsing input *and* having a BASE. It doesn't make much sense without

[bug #58050] Incorrect timeout handling when tls transport is registered

Follow-up Comment #2, bug #58050 (project wget): Thanks, pushed. ___ Reply to this item at: ___ Message sent via Savannah https://savannah.gnu.org/

[bug #58097] Wget doesn't download intermediate certificates when not supplied in the response

Update of bug #58097 (project wget): Status:None => Confirmed ___ Follow-up Comment #1: Thanks for the hint. Just opened https://gitlab.com/gnutls/gnutls/-/issues/968

[bug #20417] 503 respose is not retryable but should be

Follow-up Comment #8, bug #20417 (project wget): Please open a new issue with a detailed description - and if possible with a log file (options: --debug -olog.txt) and/or reproducer. ___ Reply to this item at:

[bug #55771] content-disposition not respected with long URLs (such as AWS)

Update of bug #55771 (project wget): Status:None => Inspected ___ Follow-up Comment #2: The current version 1.20.3 saves 'rufus-3.4p.exe' in case 3. You are using an older Mingw32

[bug #57884] wget reveals my operating system to the server

Follow-up Comment #6, bug #57884 (project wget): There seem to be concerns and actions taken by browser vendors about regarding the User-Agent header. It's about "freezing" the User-Agent string once and for all to avoid compatibility issues. Is this an option for us ?

[bug #57884] wget reveals my operating system to the server

Follow-up Comment #5, bug #57884 (project wget): I see the point but start be become curious about backwards compatibility and about how browsers and other web clients behave. Transmitting the OS type is likely not handled by GDPR, as it is likely not considered "personal data" (data that is

[bug #57884] wget reveals my operating system to the server

Update of bug #57884 (project wget): Status:None => Fixed Assigned to:None => rockdaboot Open/Closed:Open => Closed Fixed Release:

[bug #57880] wget is not following data file links

Update of bug #57880 (project wget): Status:None => Works For Me Assigned to:None => rockdaboot Open/Closed:Open => Closed

[bug #57795] Missing trailing newline character

Update of bug #57795 (project wget): Severity: 3 - Normal => 2 - Minor Status:None => Fixed Assigned to:None => rockdaboot Open/Closed:

[bug #57766] Remove group-write permission from ~/.wget-hsts file

Update of bug #57766 (project wget): Status:None => Invalid Assigned to:None => rockdaboot Open/Closed:Open => Closed

[bug #48232] Sometimes wget restarts download from the beginning, even if the server supports resumed downloads

Update of bug #48232 (project wget): Status:None => Fixed Open/Closed:Open => Closed Release:1.18 => trunk Fixed Release:

[bug #54126] Wget keeps crashing in Windows sometimes when the filename is large enough to scroll it

Follow-up Comment #7, bug #54126 (project wget): Sorry, I am not sure what your point is. You say "when USE_NLS_PROGRESS_BAR defined all works fine". But no, not at all. All those changes to prevent different types of buffer and integer overflow have *only* been tested with USE_NLS_PROGRESS_BAR

[bug #57413] No data detection, recursive mode won; t work if received HTTP responses are always comming in gzip compression

Follow-up Comment #5, bug #57413 (project wget): Hi zahlabut, leave away -i, because it consumes '-r' as a file name and thus wget doesn't work recusively. I just used your command below without '-i' and it seems to work (downloading plenty files).

[bug #57413] No data detection, recursive mode won; t work if received HTTP responses are always comming in gzip compression

Follow-up Comment #3, bug #57413 (project wget): I DID reproduce your issue (with 1.20.3 on Debian and with Wget from git master). As I said, you have to enable compression support and remove --header from your example - then your example worked here.

[bug #57413] No data detection, recursive mode won; t work if received HTTP responses are always comming in gzip compression

Update of bug #57413 (project wget): Status:None => Fixed Assigned to:None => rockdaboot Open/Closed:Open => Closed Fixed Release:

[bug #54126] Wget keeps crashing in Windows sometimes when the filename is large enough to scroll it

Follow-up Comment #5, bug #54126 (project wget): >From the mailing list: I fixed a bunch of issues found by fuzzing in the progress (bar + dot) code. The 'filename scrolling' part of the progress bar needed to be disabled and likely has to be rewritten. The changes are in branch

[bug #57356] Don't use smart quotes in output messages

Update of bug #57356 (project wget): Status:None => Wont Fix Assigned to:None => rockdaboot Open/Closed:Open => Closed

[Bug-wget] [bug #57094] When doing wget zoom into terminal splits us the download bar into several bars

Update of bug #57094 (project wget): Status:None => Fixed Assigned to:None => rockdaboot Open/Closed:Open => Closed Fixed Release:

[Bug-wget] [bug #56992] Support --retry-on-http-error ranges

Follow-up Comment #1, bug #56992 (project wget): Wget2 has something like --retry-on-http-status (we likely rename that to --retry-on-http-error before the next beta release) Specify a comma-separated list of HTTP codes in which Wget2 will retry the download. The elements of the list may

[bug #56987] Please add the highly demanded “--retry-on-http-error” feature.

Update of bug #56987 (project wget): Status:None => Invalid Open/Closed:Open => Closed ___ Reply to this item at:

[Bug-wget] [bug #56946] Performance of `-r -A` is poor

Update of bug #56946 (project wget): Assigned to:None => rockdaboot Open/Closed:Open => Closed ___ Follow-up Comment #2: The reason is, due to

[Bug-wget] [bug #56946] Performance of `-r -A` is poor

Update of bug #56946 (project wget): Status:None => Confirmed ___ Follow-up Comment #1: Yeah, quite weird. Thanks for reporting. Wget2 doesn't have this 100% CPU behavior and just

[Bug-wget] [bug #56807] Recreate files instead of rewriting them

Update of bug #56807 (project wget): Status:None => Invalid Assigned to:None => rockdaboot Open/Closed:Open => Closed

[Bug-wget] [bug #56808] wget uses HEAD method when both --spider and --post-data options are used

Follow-up Comment #1, bug #56808 (project wget): You are right. The combination of both options doesn't make much sense. Using a POST request with --spider seems to be dangerous as it leads to unexpected data / state on the server side. So this i not an option. Silently doing a GET request is

[Bug-wget] [bug #56807] Recreate files instead of rewriting them

Follow-up Comment #1, bug #56807 (project wget): Did you check the --unlink option ? ___ Reply to this item at: ___ Message sent via Savannah

[Bug-wget] [bug #56755] Saved cookies file doesn't pass cookielib's valid cookie format test

Update of bug #56755 (project wget): Status:None => Wont Fix Assigned to:None => rockdaboot Open/Closed:Open => Closed Operating System:

[Bug-wget] [bug #56660] wget -r or mirror with robots-off should still download robots.txt file

Update of bug #56660 (project wget): Status:None => Confirmed Reproducibility:None => Every Time ___ Reply to this item at:

[Bug-wget] [bug #56648] Add HTTP request header to file

Follow-up Comment #3, bug #56648 (project wget): Good that you can work on... On Debian GNU/Linux: apt-get install xattr wget --xattr www.example.com xattr -p user.xdg.origin.url index.html >out.txt cat out.txt ___ Reply to this item at:

[Bug-wget] [bug #56648] Add HTTP request header to file

Follow-up Comment #1, bug #56648 (project wget): If you copy all files and headers into one file - did you play with the WARC options ? With --xattr the original URL is saved as extended file attribute, if your file system supports it. You could use -d -olog and let a script extract URL and

[Bug-wget] [bug #56244] Bug with different quotation marks

Update of bug #56244 (project wget): Open/Closed:Open => Closed ___ Reply to this item at: ___

[Bug-wget] [bug #56244] Bug with different quotation marks

Follow-up Comment #2, bug #56244 (project wget): The syntax for attribute double-quoted values do not mention the unicode homoglyph, but clearly state the quotation mark ": https://www.w3.org/TR/2012/WD-html-markup-20120329/syntax.html#attr-value-double-quoted

[Bug-wget] [bug #56244] Bug with different quotation marks

Follow-up Comment #1, bug #56244 (project wget): Hi, while I can believe that href=“ may result in what you describe, I can't find such in one of your website files. Did you change it already to href=" ? Also I don't think we should be too relaxed with such unicode chars - there are several

[Bug-wget] [bug #56104] PatchGuidelines (from README) still explains making patches with mercurial

Update of bug #56104 (project wget): Status:None => Confirmed Assigned to:None => rockdaboot Open/Closed:Open => Closed

[Bug-wget] [bug #56103] HTTPS broken on wget.addictivecode.org (linked to from README)

Update of bug #56103 (project wget): Status:None => Confirmed Assigned to:None => rockdaboot Open/Closed:Open => Closed

[Bug-wget] [bug #56105] choco install wget: libwinpthread-1.dll is missing from your computer

Update of bug #56105 (project wget): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #1: Sorry, but we don't

[Bug-wget] [bug #56091] Spanning host -H explanation unclear meaning

Follow-up Comment #1, bug #56091 (project wget): Yes, something seems wrong there. WDYT about "Unless sufficient recursion-limiting criteria are applied, these foreign ..." ? ___ Reply to this item at:

[Bug-wget] [bug #55229] memory exhausted even though stating: Omitting download

Update of bug #55229 (project wget): Status:None => Fixed Open/Closed:Open => Closed Fixed Release:None => 1.20

[Bug-wget] [bug #55229] memory exhausted even though stating: Omitting download

Follow-up Comment #4, bug #55229 (project wget): We fixed several memleaks since wget 1.18. Please try to reproduce with the latest version (1.20). Maybe there is (or was ?) an issue that results in loading the last file (see your log) completely into memory. This is just a wild guess and not

[Bug-wget] [bug #55229] memory exhausted even though stating: Omitting download

Follow-up Comment #1, bug #55229 (project wget): Well, you download possibly *everything* from http://quantum-mirror.hu, at least all *.iso files. As I understood, you are only interested in isos from .../7.6.1810/isos/x86_64/, then you should try -np/--no-parent. This makes wget to stay in

[Bug-wget] [bug #55087] Please add parsing of picture element sources to `wget -r`

Follow-up Comment #1, bug #55087 (project wget): Wget2 already supports it. Eventually we backport it to Wget1.x. ___ Reply to this item at: ___

[Bug-wget] [bug #54963] wget -c treats a 416 response as a failure

Update of bug #54963 (project wget): Open/Closed:Open => Closed Release: 1.19.5 => 1.19.2 Planned Release:None => 1.19.6

[Bug-wget] [bug #54963] wget -c treats a 416 response as a failure

Update of bug #54963 (project wget): Status:None => Confirmed ___ Follow-up Comment #3: Sorry, I have to correct myself. You are right, it is a regression introduced in 1.19.2 (commit

[Bug-wget] [bug #54963] wget -c treats a 416 response as a failure

Update of bug #54963 (project wget): Assigned to:None => rockdaboot ___ Follow-up Comment #2: robots.txt is an exception regarding 416 responses. It will always be fully retrieved (have to

[Bug-wget] [bug #54839] Building takes gnutls include from /usr/local/include, but libgnutls.so from system dir

Update of bug #54839 (project wget): Status:None => Fixed Open/Closed:Open => Closed ___ Follow-up Comment #1: Has been fixed in

[Bug-wget] [bug #54839] Building takes gnutls include from /usr/local/include, but libgnutls.so from system dir

URL: Summary: Building takes gnutls include from /usr/local/include, but libgnutls.so from system dir Project: GNU Wget Submitted by: rockdaboot Submitted on: Mon 15 Oct 2018 01:16:50 PM CEST

[Bug-wget] [bug #54825] unexpected wget appends .1 after the file extension

Follow-up Comment #8, bug #54825 (project wget): If you have certain things in mind, issues at https://gitlab.com/gnuwget/wget2/issues are appreciated. ___ Reply to this item at:

[Bug-wget] [bug #54826] too much output on wget --version

Follow-up Comment #7, bug #54826 (project wget): Oh good point, we forgot it so far :-) At least we have to add the Copyright and bug report lines. The Wgetrc/Locale/Compile/Link stuff should be ok with a different option, e.g. --version in combination with --debug or so.

[Bug-wget] [bug #54826] too much output on wget --version

Follow-up Comment #5, bug #54826 (project wget): The best reason to *keep* that ouput is that is was put like that ~10years (or maybe 20 ?) ago. There are production scripts out there that parse the output of wget --version. Apart from that, you are right. And I wish we could just drop bw

[Bug-wget] [bug #54825] unexpected wget appends .1 after the file extension

Follow-up Comment #6, bug #54825 (project wget): You can make your own default and put it into ~/.wget2rc or any other file set by $WGET2RC or by --config. But the hard-coded default will be kept as to make wget2 as nearly compatible to wget as possible. So it can be used as drop-in replacement

[Bug-wget] [bug #54825] unexpected wget appends .1 after the file extension

Follow-up Comment #4, bug #54825 (project wget): Just want to add that Wget2 has --keep-extension (commit c9796a174d04099d07dd7dc70da47ea92d3ba3a6). E.g. that generates index_1.html instead of index.html.1. ___ Reply to this item at:

[Bug-wget] [bug #54710] Just a typing error

Update of bug #54710 (project wget): Status:None => Invalid Assigned to:None => rockdaboot Open/Closed:Open => Closed Release:

[Bug-wget] [bug #54769] Disable automatic wget headers

Update of bug #54769 (project wget): Privacy: Private => Public ___ Follow-up Comment #1: Tagging it 'public'. 'private' is for security/privacy issues.

[Bug-wget] [bug #54677] PCRE2 support https://pcre.org/

Update of bug #54677 (project wget): Severity: 3 - Normal => 1 - Wish Status:None => Fixed Assigned to:None => rockdaboot Open/Closed:

[Bug-wget] [bug #54596] wget gets a lot of file named "index.html?............" and other strange file names

Update of bug #54596 (project wget): Status:None => Invalid Open/Closed:Open => Closed ___ Follow-up Comment #1: This is expected

[Bug-wget] [bug #51666] Please hash the hostname in ~/.wget-hsts files

Follow-up Comment #5, bug #51666 (project wget): Thanks for addressing the issue. Saving the salt together with the (salted) hash isn't of big help when we talk about a limited set of input strings. You can get complete lists of existing domains and brute force through them in a few seconds. Can

[Bug-wget] [bug #54178] wget sometimes returns 1024

Update of bug #54178 (project wget): Status:None => Inspected Open/Closed:Open => Closed ___ Reply to this item at:

  1   2   3   4   5   6   7   8   9   >